Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

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,

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Re: [PATCH 2/2] completion: simplify _git_notes

> 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

[PATCH v2 0/4] nd/parseopt-completion fixups

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 ---

[PATCH v2 3/4] completion: complete --{reuse,reedit}-message= for all notes subcmds

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:

[PATCH v2 1/4] completion: don't set PARSE_OPT_NOCOMPLETE on --rerere-autoupdate

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

[PATCH v2 2/4] completion: simplify _git_notes

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

[PATCH v2 4/4] completion: more subcommands in _git_notes()

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 ++--

Re: [PATCH] xdiff: improve trimming preprocessing

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

Re: [PATCH v9 4/8] utf8: add function to detect a missing UTF-16/32 BOM

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

What's cooking in git.git (Mar 2018, #02; Tue, 6)

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Git / Software Freedom Conservancy status report (2018)

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:

Re: [PATCH v9 4/8] utf8: add function to detect a missing UTF-16/32 BOM

> 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

Re: [PATCH v9 4/8] utf8: add function to detect a missing UTF-16/32 BOM

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

Re: [PATCH] xdiff: improve trimming preprocessing

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

git-scm.com update

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

Re: [PATCH v9 4/8] utf8: add function to detect a missing UTF-16/32 BOM

> 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

Re: [PATCH v9 4/8] utf8: add function to detect a missing UTF-16/32 BOM

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

Re: [PATCH 2/2] completion: simplify _git_notes

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;

Re: [PATCH v9 4/8] utf8: add function to detect a missing UTF-16/32 BOM

> 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,

Re: [PATCH 2/2] git-svn: allow empty email-address in authors-prog and authors-file

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

Re: [PATCH v9 5/8] convert: add 'working-tree-encoding' attribute

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()

Re: [PATCH v9 5/8] convert: add 'working-tree-encoding' attribute

> 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 >>

QUICK REPLY

Would you like to be part of our supply? Please respond back to my private email on: kuanwaich...@gmail.com

Re: [PATCH v2 1/3] add -p: select individual hunk lines

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

Re: [GSoC][PATCH v4] Make options that expect object ids less chatty if id is invalid

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

Re: [PATCH v2 0/3] add -p: select individual hunk lines

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

Re: [GSoC][PATCH v4] Make options that expect object ids less chatty if id is invalid

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

Re: [PATCH v9 0/8] convert: add support for different encodings

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

Re: [PATCH v2 0/3] add -p: select individual hunk lines

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"

Re: [PATCH v9 6/8] convert: check for detectable errors in UTF encodings

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

Re: [PATCH v9 4/8] utf8: add function to detect a missing UTF-16/32 BOM

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,

Re: [PATCH v9 5/8] convert: add 'working-tree-encoding' attribute

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.

Re: [PATCH v2 2/3] add -p: allow line selection to be inverted

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/ > >

Re: [PATCH v2 3/3] add -p: optimize line selection for short hunks

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

Re: [PATCH v2 1/3] add -p: select individual hunk lines

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

Re: [RFC PATCH] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

(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

Re: [PATCH v2 0/3] add -p: select individual hunk lines

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

Re: [PATCH v2 2/3] add -p: allow line selection to be inverted

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

Re: [GSoC][PATCH v3] Make options that expect object ids less chatty if id is invalid

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

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 >

[GSoC][PATCH v4] Make options that expect object ids less chatty if id is invalid

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",

Re: [PATCH] xdiff: improve trimming preprocessing

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

Bug: moving submodules that have submodules inside them causes a fatal error in git status

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

Re: [PATCH] git-gui: Add hotkeys to change focus between ui widgets

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

Re: [PATCH] xdiff: improve trimming preprocessing

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

Re: [PATCH v2 3/5] gc --auto: exclude base pack if not enough mem to "repack -ad"

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

Re: [PATCH v2 2/5] repack: add --keep-pack option

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Re: [PATCH v2 1/5] fixup! Add a test showing that 'git repack' throws away grafted-away parents

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

Re: [PATCH v2 0/5] Avoid expensive 'repack -ad' in gc --auto

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

Re: [PATCH v9 6/8] convert: check for detectable errors in UTF encodings

> 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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Improve `git log -L` functionality

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

How to use filter-branch with --state-branch?

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

Re: [PATCH] git-gui: Add hotkeys to change focus between ui widgets

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

[RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Re: [PATCH] git.el: handle default excludesfile properly

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

[PATCH] xdiff: improve trimming preprocessing

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Reply

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

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

[PATCH v2 5/5] pack-objects: display progress in get_object_details()

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

[PATCH v2 4/5] pack-objects: show some progress when counting kept objects

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

[PATCH v2 3/5] gc --auto: exclude base pack if not enough mem to "repack -ad"

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

[PATCH v2 0/5] Avoid expensive 'repack -ad' in gc --auto

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

[PATCH v2 2/5] repack: add --keep-pack option

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

[PATCH v2 1/5] fixup! Add a test showing that 'git repack' throws away grafted-away parents

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

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

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

Re: [PATCH v5 0/9] Correct offsets of hunks when one is skipped

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

Re: [PATCH 1/2] completion: don't set PARSE_OPT_NOCOMPLETE on --rerere-autoupdate

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

[PATCH v2 1/3] add -p: select individual hunk lines

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).

[PATCH v2 3/3] add -p: optimize line selection for short hunks

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

[PATCH v2 2/3] add -p: allow line selection to be inverted

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 -

[PATCH v2 0/3] add -p: select individual hunk lines

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

[PATCH 1/2] object.h: update flag allocation comment

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

[PATCH 2/2] object.h: realign object flag allocation comment

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

Re: [Bug] git log --show-signature print extra carriage return ^M

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

Re: [GSoC] [PATCH] travis-ci: added clang static analysis

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

Re: git-send-email: Support for Reply-To

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