Since the "flags" is shared, it's a good idea to keep track of who
uses what bit. When we need to use more flags in library code, we can
be sure it won't be re-used for another purpose by some caller.
While at there, fix the location of "5" (should be in a different
column than "4" two lines down)
From: Phillip Wood
If the list of lines to be selected begins with '^' select all the
lines except the ones listed.
Signed-off-by: Phillip Wood
---
Documentation/git-add.txt | 3 ++-
git-add--interactive.perl | 17 -
t/t3701-add-interactive.sh | 2 +-
3 files changed, 19 in
From: Phillip Wood
When I end up editing hunks it is almost always because I want to
stage a subset of the lines in the hunk. Doing this by editing the
hunk is inconvenient and error prone (especially so if the patch is
going to be reversed before being applied). Instead offer an option
for add -
From: Phillip Wood
If there are fewer than ten changes in a hunk then make spaces
optional when selecting individual lines. This means that for short
hunks one can just type -357 to stage lines 1, 2, 3, 5 & 7.
Signed-off-by: Phillip Wood
---
Documentation/git-add.txt | 3 ++-
git-add--intera
From: Phillip Wood
I've added some documentation to git-add.txt for the new selection
mode and cleaned up some style issues, otherwise these are unchanged
since v1. These patches build on top of the recount fixes in [1]. The
commit message for the first patch describes the motivation:
"When I e
On 03/03/18 09:23, Nguyễn Thái Ngọc Duy wrote:
>
> There is not a strong reason to hide this option, and git-merge already
> completes this one. Let's allow to complete this for all commands (and
> let git-completion.bash do the suppressing if neede).
>
> This makes --rerere-autoupdate completabl
On 05/03/18 18:50, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> I've updated these to clean up the perl style in response to Junio's
>> comments on v4.
>
> I've considered the use of "apply --recount" in this script (eh,
> rather, the existence of that option in "a
On 02/03/18 23:33, Igor Djordjevic wrote:
> Hi Phillip,
>
>> On Fri, Mar 2, 2018 at 4:36 AM, Phillip Wood wrote:
>>>
It is interesting to think what it means to faithfully rebase a '-s
ours' merge.
>>>
>>> I should have explained that I mean is a faithful rebase one that
>>> adheres to t
I'm pretty happy with this now. Like v1, this is about not touching
the giant base pack when doing background gc. This saves about 2/3 of
memory, which in turn should improve performance if you're under
memory pressure.
v2 changes:
- the core idea remains the same, mem_have is increased to half t
We allow to keep existing packs by having companion .keep files. This
is helpful when a pack is permanently kept. In the next patch, git-gc
just wants to keep a pack temporarily, for one pack-objects
run. git-gc can use --keep-pack for this use case.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Docum
pack-objects could be a big memory hog especially on large repos,
everybody knows that. The suggestion to stick a .keep file on the
giant base pack to avoid this problem is also known for a long time.
Let's do the suggestion automatically instead of waiting for people to
come to Git mailing list a
The closing quote of a test body by convention is always at the start
of line.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t7700-repack.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 6061a04147..38247afbec 100755
--- a/t/t7700-rep
This code is mostly about reading object headers, which is cheap. But
when the number of objects is very large (e.g. 6.5M on linux-2.6.git)
and the system is under memory pressure, this could take some time (86
seconds on my system).
Show something during this time to let the user know pack-object
We only show progress when there are new objects to be packed. But
when --keep-pack is specified on the base pack, we will exclude most
of objects. This makes 'pack-objects' stay silent for a long time
while the counting phase is going.
Let's show some progress whenever we visit an object instead.
On 03/03/18 00:29, Igor Djordjevic wrote:
> Hi Phillip,
>
> On 02/03/2018 12:31, Phillip Wood wrote:
>>
>>> Thinking about it overnight, I now suspect that original proposal had a
>>> mistake in the final merge step. I think that what you did is a way to
>>> fix it, and I want to try to figure wha
On 05/03/18 05:00, Sergey Organov wrote:
> Hi Plillip and Igor,
>
> Igor Djordjevic writes:
>> Hi Phillip,
>>
>> On 02/03/2018 12:31, Phillip Wood wrote:
>>>
Thinking about it overnight, I now suspect that original proposal had a
mistake in the final merge step. I think that what you di
Dear Doron,
I plead an indulgence if I have invaded your privacy by receiving this
mail from me without prior permission. With due respect, I contact you
purposely based on the similarities of names between you and my
deceased client who was an oil servicing contractor with shell
petroleum in West
Hi Phillip,
Phillip Wood writes:
> On 03/03/18 00:29, Igor Djordjevic wrote:
>> Hi Phillip,
[...]
>>
>> The only thing I wonder of here is how would we check if the
>> "rebased" merge M' was "clean", or should we stop for user amendment?
>> With that other approach Sergey described, we have
xdiff-interface trims common suffix if ctxlen is 0. Teach it to also
trim common prefix, and trim less lines if ctxlen > 0. So it can benefit
the default diff command, as seen by profiling:
$ GIT_PERF_REPEAT_COUNT=10 ./run origin/master . -- p4000-diff-algorithms.sh
[...]
Test
Junio C Hamano writes:
> Having said that, I am sorry to say that I am not sure if the copy
> we have is the one to be patched, so I would appreciate if Alexandre
> (cc'ed) can clarify the situation. The last change done to our copy
> of the script is from 2012, and I do not know if Alexandre is
Hi,
This is v2 of my "Rebasing merges" proposal.
Significant changes are:
1. Fixed mistake in the final merge step in the original proposal: wrong
merge base was used. Thanks everybody who provided test-cases, and
special thanks to Igor Djordjevic for
implementing and testing a few var
Thanks for the feedback.
On Mon, Mar 5, 2018 at 5:55 PM, Johannes Schindelin
wrote:
> Do you think there is a way to focus on the last-selected path? That would
> make this feature even more convenient, I think.
Yes, good idea. I'll implement it and create a second version.
> I am not sure that
Recent versions of git filter-branch command introduced the --state-branch
option.
BTW I can't find any info about how this can be actually used.
We have this repository on github:
https://github.com/concrete5/concrete5
When someone pushes to that repo, we clone it and execute
`git filter-branch
Hi.
I want to `Trace the evolution of the line range`.
And not committed change is sort of evolution and should be taken into account
by -L option.
Currently I MUST `stash save` change,
look actual line number,
trace evolution,
`stash pop` to bring back current change.
EXPECTED:
Allow to
Phillip Wood writes:
> I wonder if just having a predicable result rather than forcing the
> rebase to stop if the user just squashes a fixup commit into a topic
> branch that is the parent of a merge might be more convenient in practice.
Unless I am misunderstanding what you are saying, that is
> On 06 Mar 2018, at 02:23, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> On 05 Mar 2018, at 22:50, Junio C Hamano wrote:
>>>
>>> lars.schnei...@autodesk.com writes:
>>>
+static int validate_encoding(const char *path, const char *enc,
+const char *data, si
Nguyễn Thái Ngọc Duy writes:
> I'm pretty happy with this now. Like v1, this is about not touching
> the giant base pack when doing background gc. This saves about 2/3 of
> memory, which in turn should improve performance if you're under
> memory pressure.
Thanks. I've quickly scanned them and
Nguyễn Thái Ngọc Duy writes:
> The closing quote of a test body by convention is always at the start
> of line.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
Obviously correct. While the title may technically be correct, the
original commit is age old that we won't be amending it anyway, and
Hi Phillip & Buga,
On Tue, 6 Mar 2018, Phillip Wood wrote:
> On 02/03/18 23:33, Igor Djordjevic wrote:
> >
> > [...]
> > Otherwise, I would be interested to learn how context/semantics
> > guessing could provide a better default action (without introducing
> > more complexity for might not be
Hi Phillip,
On Tue, 6 Mar 2018, Phillip Wood wrote:
> On 03/03/18 00:29, Igor Djordjevic wrote:
> >
> > On 02/03/2018 12:31, Phillip Wood wrote:
> >>
> >>> Thinking about it overnight, I now suspect that original proposal
> >>> had a mistake in the final merge step. I think that what you did is
Nguyễn Thái Ngọc Duy writes:
> +--keep-pack=::
> + Ignore the given pack. This is the equivalent of having
> + `.keep` file on the pack. Implies `--honor-pack-keep`.
> +
A few questions I am not sure how I would answer:
- Do we want to have this listed in the SYNOPSIS section, too?
Nguyễn Thái Ngọc Duy writes:
> On linux-2.6.git, valgrind massif reports 1.6GB heap in "pack all"
> case, and 535MB [1] in "pack all except the base pack" case. We save
> roughly 1GB memory by excluding the base pack.
;-)
> gc --auto decides to do this based on an estimation of pack-objects
>
On Tue, Mar 6, 2018 at 6:53 AM, Jun Wu wrote:
> xdiff-interface trims common suffix if ctxlen is 0. Teach it to also
> trim common prefix, and trim less lines if ctxlen > 0. So it can benefit
> the default diff command, as seen by profiling: [...]
A few comments (below) based upon a quick scan of
Birger Skogeng Pedersen writes:
> Thanks for the feedback.
>
> On Mon, Mar 5, 2018 at 5:55 PM, Johannes Schindelin
> wrote:
>> Do you think there is a way to focus on the last-selected path? That would
>> make this feature even more convenient, I think.
>
> Yes, good idea. I'll implement it and
Hello,
I encountered this error when moving some submodules in vim, basically if you
have a submodule that has submodules inside it and you try to move it you'll
encouter a fatal error with `git status`. I have a pastebin example of this
here: https://ptpb.pw/5g9-/bash
Appologies if this is an in
Eric Sunshine writes:
> On Tue, Mar 6, 2018 at 6:53 AM, Jun Wu wrote:
>> xdiff-interface trims common suffix if ctxlen is 0. Teach it to also
>> trim common prefix, and trim less lines if ctxlen > 0. So it can benefit
>> the default diff command, as seen by profiling: [...]
I vaguely recall tha
Usually, the usage should be shown only if the user does not know what
options are available. If the user specifies an invalid value, the user
is already aware of the available options. In this case, there is no
point in displaying the usage anymore.
This patch applies to "git tag --contains", "gi
On 06/03/2018 19:12, Johannes Schindelin wrote:
>
> > > And I guess being consistent is pretty important, too - if you add new
> > > content during merge rebase, it should always show up in the merge,
> > > period.
> >
> > Yes, that should make it easy for the user to know what to expect from
> >
Hello Junio,
Thank you for reviewing my code. I appreciate it. I made the changes
here [1].
On Mon, 2018-03-05 at 16:19 -0800, Junio C Hamano wrote:
> Taking these together, I _think_ this patch is moving things in the
> right direction, in that it allows callers of parse_options_step()
> to tell
Phillip Wood writes:
> From: Phillip Wood
>
> If the list of lines to be selected begins with '^' select all the
> lines except the ones listed.
There is "# Input that begins with '-'; unchoose" in list_and_choose
helper. Does it make things inconsistent to use '^' for negation
like this patch
Hi Phillip,
On 06/03/2018 11:17, Phillip Wood wrote:
>
> From: Phillip Wood
>
> I've added some documentation to git-add.txt for the new selection
> mode and cleaned up some style issues, otherwise these are unchanged
> since v1. These patches build on top of the recount fixes in [1]. The
> co
(cc list snipped)
Hi,
Eddy Petrișor wrote:
> Cc: [a lot of people]
Can you say a little about how this cc list was created? E.g. should
"git send-email" get a feature to warn about long cc lists?
> Signed-off-by: Eddy Petrișor
> ---
>
> There are projects such as llvm/clang which use several
On 06/03/2018 11:17, Phillip Wood wrote:
> From: Phillip Wood
>
> When I end up editing hunks it is almost always because I want to
> stage a subset of the lines in the hunk. Doing this by editing the
> hunk is inconvenient and error prone (especially so if the patch is
> going to be reversed bef
On 06/03/2018 11:17, Phillip Wood wrote:
> From: Phillip Wood
>
> If there are fewer than ten changes in a hunk then make spaces
> optional when selecting individual lines. This means that for short
Not sure if using s/selecting individual lines/staging individual lines/
would make sense here,
On 06/03/2018 11:17, Phillip Wood wrote:
> From: Phillip Wood
>
> If the list of lines to be selected begins with '^' select all the
> lines except the ones listed.
s/to be selected begins with '^' select all/to be staged begins with '^' stage
all/
>
> Signed-off-by: Phillip Wood
> ---
> Do
On Sun, Mar 4, 2018 at 3:14 PM, wrote:
> Git recognizes files encoded with ASCII or one of its supersets (e.g.
> UTF-8 or ISO-8859-1) as text files. All other encodings are usually
> interpreted as binary and consequently built-in Git text processing
> tools (e.g. 'git diff') as well as most Git
lars.schnei...@autodesk.com writes:
> +int is_missing_required_utf_bom(const char *enc, const char *data, size_t
> len)
> +{
> + return (
> +!strcmp(enc, "UTF-16") &&
> +!(has_bom_prefix(data, len, utf16_be_bom, sizeof(utf16_be_bom)) ||
> + has_bom_prefix(data, len, u
On Sun, Mar 4, 2018 at 3:14 PM, wrote:
> Check that new content is valid with respect to the user defined
> 'working-tree-encoding' attribute.
>
> Signed-off-by: Lars Schneider
> ---
> diff --git a/convert.c b/convert.c
> @@ -266,6 +266,53 @@ static int will_convert_lf_to_crlf(size_t len, struct
Igor Djordjevic writes:
> A small nitpick - I see you use phrasing like "select lines", where
> the other commands usually talk about "staging", instead, so "stage
> lines" might be more aligned with the existing text.
Isn't this machinery shared across "add -p" and "reset -p"? What is
done t
On Sun, Mar 4, 2018 at 3:14 PM, wrote:
> Changes since v8: [...]
>
> Thanks a lot Eric for your great review! I think I fixed everything you
> objected with one exception. You noticed that the current code only
> checks for BOMs corresponding to the declared size (16 or 32 bits) [1].
> I understa
Paul-Sebastian Ungureanu writes:
> Usually, the usage should be shown only if the user does not know what
> options are available. If the user specifies an invalid value, the user
> is already aware of the available options. In this case, there is no
> point in displaying the usage anymore.
>
> T
Hi Junio,
On 06/03/2018 22:03, Junio C Hamano wrote:
>
> > A small nitpick - I see you use phrasing like "select lines", where
> > the other commands usually talk about "staging", instead, so "stage
> > lines" might be more aligned with the existing text.
>
> Isn't this machinery shared across
Junio C Hamano writes:
> I kind of find it surprising that the one single case I happened to
> have noticed is the only one that needed special treatment. Did you
> go though all the codepath and made sure that the ones that still
> return -1 (not -2 and not -3) to parse_options_step() are all O
On 06/03/2018 21:29, Igor Djordjevic wrote:
>
> > diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> > index f83e7450ad..a273b41e95 100755
> > --- a/git-add--interactive.perl
> > +++ b/git-add--interactive.perl
> >
> > [...]
> >
> > @@ -1255,6 +1382,7 @@ j - leave this hunk und
Would you like to be part of our supply?
Please respond back to my private email
on: kuanwaich...@gmail.com
> On 06 Mar 2018, at 21:42, Eric Sunshine wrote:
>
> On Sun, Mar 4, 2018 at 3:14 PM, wrote:
>> Git recognizes files encoded with ASCII or one of its supersets (e.g.
>> UTF-8 or ISO-8859-1) as text files. All other encodings are usually
>> interpreted as binary and consequently built-in Git tex
On Tue, Mar 6, 2018 at 5:13 PM, Lars Schneider wrote:
>> On 06 Mar 2018, at 21:42, Eric Sunshine wrote:
>> On Sun, Mar 4, 2018 at 3:14 PM, wrote:
>>> + return xstrdup_toupper(value);
>>
>> xstrdup_toupper() allocates memory...
>>
>>> + const char *working_tree_encoding; /* Supported
Am 05.03.2018 um 10:37 schrieb Andreas Heiduk:
> 2018-03-05 2:42 GMT+01:00 Eric Sunshine :
>> On Sun, Mar 4, 2018 at 6:22 AM, Andreas Heiduk wrote:
>>> ---
>>> diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
>>> @@ -1482,7 +1482,6 @@ sub call_authors_prog {
>>> }
>>> if ($author =~
> On 06 Mar 2018, at 21:50, Junio C Hamano wrote:
>
> lars.schnei...@autodesk.com writes:
>
>> +int is_missing_required_utf_bom(const char *enc, const char *data, size_t
>> len)
>> +{
>> +return (
>> + !strcmp(enc, "UTF-16") &&
>> + !(has_bom_prefix(data, len, utf16_be_bom, siz
SZEDER Gábor writes:
> There is a minor behaviour change here, though. This
>
> prune,*)
> ;;
>
> case arm ensured that we don't list refs for 'git notes prune ',
> because it doesn't accept them (and then we take our usual fallback and
> let Bash complete filenames; yeah, 'git notes prun
Lars Schneider writes:
>> Also "UTF16" or other spelling
>> the platform may support but this code fails to recognise will go
>> unchecked.
>
> That is true. However, I would assume all iconv implementations use the
> same encoding names for UTF encodings, no? That means UTF16 would never be
> v
> On 06 Mar 2018, at 23:53, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> Also "UTF16" or other spelling
>>> the platform may support but this code fails to recognise will go
>>> unchecked.
>>
>> That is true. However, I would assume all iconv implementations use the
>> same encoding
Last year I reported on the state of the git-scm.com website:
https://public-inbox.org/git/20170202023349.7fopb3a6pc6dk...@sigill.intra.peff.net/
There was a little bit of public discussion, and I privately got
approximately one zillion offers to host the site or otherwise help with
it. Thank
Excerpts from Eric Sunshine's message of 2018-03-06 14:23:46 -0500:
> On Tue, Mar 6, 2018 at 6:53 AM, Jun Wu wrote:
> > + printf "x%.0s" {1..934} >>d # pad common suffix to 1024 bytes
>
> The expression {x..y} is not portable to non-POSIX shells.
Is there a recommended way to generate a repetit
Junio C Hamano writes:
> Lars Schneider writes:
>
>>> Also "UTF16" or other spelling
>>> the platform may support but this code fails to recognise will go
>>> unchecked.
>>
>> That is true. However, I would assume all iconv implementations use the
>> same encoding names for UTF encodings, no? T
> On 07 Mar 2018, at 00:07, Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
>> Lars Schneider writes:
>>
Also "UTF16" or other spelling
the platform may support but this code fails to recognise will go
unchecked.
>>>
>>> That is true. However, I would assume all iconv impl
It's been about a year since I sent a big update regarding our
activities with Conservancy. So I'm going to pretend that it was all a
plan to have an annual report, and this is the 2018 one. The previous
report can be found at:
https://public-inbox.org/git/20170202024501.57hrw4657tsqe...@sigill
Hi Johannes,
On 05/03/2018 18:29, Johannes Schindelin wrote:
>
> > By the way, is there documentation for `git merge-recursive`
> > anywhere, besides the code itself...? :$
>
> I am not aware of any. The commit message adding the command is not very
> illuminating (https://github.com/git-for-wi
Johannes Schindelin writes:
>> I don't think its possible to guess the semantics of the original merge
>> as users can use custom merge strategies and amend the result. It would
>> be possible to detect and unamended '-s ours' merge but special casing
>> that may end up causing users more confusi
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
I haven't seen enough reviews (nor
Lars Schneider writes:
> After thinking about it I wonder if we should barf on "utf16" without
> dash. Your Linux iconv would handle this correctly. My macOS iconv would not.
> That means the repo would checkout correctly on your machine but not on mine.
>
> What do you think?
To be bluntly hone
Excerpts from Junio C Hamano's message of 2018-03-06 11:29:44 -0800:
> Eric Sunshine writes:
>
> > On Tue, Mar 6, 2018 at 6:53 AM, Jun Wu wrote:
> >> xdiff-interface trims common suffix if ctxlen is 0. Teach it to also
> >> trim common prefix, and trim less lines if ctxlen > 0. So it can benefit
This also adds completion for 'git notes remove' and 'git notes edit'.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
contrib/completion/git-completion.bash | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/g
Two subcommands are added for completion: merge and get-ref. get-ref
is more like plumbing. But since it does not share the prefix with any
other subcommands, it won't slow anybody down.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
contrib/completion/git-completion.bash | 4 ++--
1 file changed, 2 in
v2 fixes the comments from v1 and adds to new patches to improve
_git_notes() (sorry I couldn't resist)
Interdiff with what's on 'pu'
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 5f7495cda3..2e30950299 100644
--- a/contrib/completion/git-comp
The new subcommand that takes these options is 'git notes edit'. Just
accept the options from subcommands since we handle them the same way
in builtin/notes.c anyway. If a user does
git prune --reuse-message=...
just let the command catches that error when it's executed.
Signed-off-by: Nguyễ
There is not a strong reason to hide this option, and git-merge already
completes this one. Let's allow to complete this for all commands (and
let git-completion.bash do the suppressing if needed).
This makes --rerere-autoupdate completable for am, cherry-pick and
revert. rebase completion is fixe
> SZEDER Gábor writes:
>
> > There is a minor behaviour change here, though. This
> >
> > prune,*)
> > ;;
> >
> > case arm ensured that we don't list refs for 'git notes prune ',
> > because it doesn't accept them (and then we take our usual fallback and
> > let Bash complete filenames;
Hi Johannes,
Johannes Schindelin writes:
> Hi Phillip,
>
> On Tue, 6 Mar 2018, Phillip Wood wrote:
>
>> On 03/03/18 00:29, Igor Djordjevic wrote:
>> >
>> > On 02/03/2018 12:31, Phillip Wood wrote:
>> >>
>> >>> Thinking about it overnight, I now suspect that original proposal
>> >>> had a mistak
Hi Sergey,
On Tue, 6 Mar 2018, Sergey Organov wrote:
> This is v2 of my "Rebasing merges" proposal.
Didn't we settle on Phillip's "perform successive three-way merges between
the original merge commit and the new tips with the old tips as base"
strategy? It has the following advantages:
- it is
Hi Sergey,
On Wed, 7 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
>
> > On Tue, 6 Mar 2018, Phillip Wood wrote:
> >
> >> On 03/03/18 00:29, Igor Djordjevic wrote:
> >> >
> >> > On 02/03/2018 12:31, Phillip Wood wrote:
> >> >>
> >> >>> Thinking about it overnight, I now suspect
Hi Buga,
On Wed, 7 Mar 2018, Igor Djordjevic wrote:
> On 05/03/2018 18:29, Johannes Schindelin wrote:
> >
> > > By the way, is there documentation for `git merge-recursive`
> > > anywhere, besides the code itself...? :$
> >
> > I am not aware of any. The commit message adding the command is not
Hi Junio,
On Tue, 6 Mar 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I don't think its possible to guess the semantics of the original merge
> >> as users can use custom merge strategies and amend the result. It would
> >> be possible to detect and unamended '-s ours' merge
Hi Buga,
On Tue, 6 Mar 2018, Igor Djordjevic wrote:
> On 06/03/2018 19:12, Johannes Schindelin wrote:
> >
> > > > And I guess being consistent is pretty important, too - if you add new
> > > > content during merge rebase, it should always show up in the merge,
> > > > period.
> > >
> > > Yes, t
Christian Ludwig writes:
> this is the third iteration of this series. There was a request to
> rebase the changes on the refactoring patch b6049542 ("send-email:
> extract email-parsing code into a subroutine", 2017-12-15). This is
> the result.
Thanks. Let me Cc the party who did the refactor
On Tue, Mar 6, 2018 at 6:57 AM, Junio C Hamano wrote:
> SiddharthaMishra writes:
>
>> Added a job to run clang static code analysis on the master and maint branch
>>
>> Signed-off-by: SiddharthaMishra
>> ---
>
> Why on 'master' and 'maint' and not others? Quite frankly, I find
> this choice of
The same ^M is shown in the output of tutorial
https://www.geekality.net/2017/08/23/setting-up-gpg-signing-for-gitgithub-on-windows/
at item "4. Verify commit was signed"
I confirm the output is right (no ^M characters) with commands
git verify-commit HEAD
git -p verify-commit HEAD
Some new path names are too long and eat into the graph part. Move the
graph 9 columns to the right to avoid this.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
object.h | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/object.h b/object.h
index 159
88 matches
Mail list logo
