Re: [PATCH 5/6] builtin/grep.c: show column numbers via --column-number

Am 21.04.2018 um 06:14 schrieb Junio C Hamano: > Junio C Hamano writes: > >> Taylor Blau writes: >> >>> This commit teaches 'git-grep(1)' a new option, '--column-number'. This >>> ... >>> +`columnnumber`;; >>> + column number prefix (when using `-m`) >>

Re: [PATCH v1 1/2] merge: Add merge.renames config setting

Elijah Newren writes: +merge.renames:: + Whether and how Git detects renames. If set to "false", + rename detection is disabled. If set to "true", basic rename + detection is enabled. This is the default. >>> >>> >>> One can already

Re: [PATCH 5/6] builtin/grep.c: show column numbers via --column-number

Junio C Hamano writes: > Taylor Blau writes: > >> This commit teaches 'git-grep(1)' a new option, '--column-number'. This >> ... >> +`columnnumber`;; >> +column number prefix (when using `-m`) > > Is there other people's tool (preferrably some variant

Re: [PATCH 5/6] builtin/grep.c: show column numbers via --column-number

Taylor Blau writes: > This commit teaches 'git-grep(1)' a new option, '--column-number'. This > ... > +`columnnumber`;; > + column number prefix (when using `-m`) Is there other people's tool (preferrably some variant of "grep") that has an option to tell it to show the

Re: [PATCH v1] perf/aggregate: tighten option parsing

Ævar Arnfjörð Bjarmason writes: >> Not necessarily worth a re-roll. > > Not that it matters in this case, but just as a bit of Perl rx pedantry, > yes his is tighter & more correct. You didn't consider how "." interacts > with newlines: > > $ perl -wE 'my @rx = (qr/^--./,

[PATCH 3/6] grep.[ch]: teach columnnum, color_columnno to grep_opt

In preparation of adding --column-number to 'git-grep(1)', we extend grep_opt to take in the requisite new members. We additionally teach the 'grep.columnnumber' and 'color.grep.columnumber' configuration variables to configure showing and coloring the column number, respectively. (These options

[PATCH 4/6] grep.c: display column number of first match

Building upon our work in the previous commit to add members 'columnnum' and 'color_columno' to 'grep_opt', we teach show_line() how to respect those options. When requested, show_line() will display the column number of the first match on a non-context line. show_line() differentiates between

[PATCH 5/6] builtin/grep.c: show column numbers via --column-number

This commit teaches 'git-grep(1)' a new option, '--column-number'. This option builds upon previous commits to show the column number of the first match on a non-context line. For example: $ git grep -mn example | head -n3 .clang-format:51:14:# myFunction(foo, bar, baz);

[PATCH 2/6] grep.c: take column number as argument to show_line()

show_line() currently receives the line number within the 'grep_opt->buf' in order to determine which line number to display. In order to display information about the matching column number--if requested--we must additionally take in that information. To do so, we extend the signature of

[PATCH 6/6] contrib/git-jump/git-jump: use column number when grep-ing

This patch adds the '--column-number' synonym '-m' to the default grep command so that callers are brought to the correct line _and_ column of each matched location. Signed-off-by: Taylor Blau --- contrib/git-jump/git-jump | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 0/6] Teach '--column-number' to 'git-grep(1)'

Hi, Attached is a series to add --column-number to 'git-grep(1)', and support jumping to the correct column when using Peff's 'git-jump'. I have chosen -m as the short form of --column-number, because -c was taken, and -m is close to -n (the short form of --line-number). The description in each

[PATCH 1/6] grep.c: take regmatch_t as argument in match_line()

In a subsequent patch, we teach show_line() to optionally include the column number of the first match on each matched line. The regmatch_t involved in match_line() and match_one_pattern() both contain this information (via regmatch_t->rm_so), but their current implementation throws this stack

Re: [PATCH v3] fast-export: fix regression skipping some merge-commits

Martin Ågren writes: > +test_expect_success 'merge commit gets exported with --import-marks' ' > + test_create_repo merging && > + ( > + cd merging && > + test_commit initial && > + git checkout -b topic && > +

Re: Silly "git gc" UI issue.

Simon Ruderich writes: > On Thu, Apr 19, 2018 at 02:10:40PM +0900, Junio C Hamano wrote: >> diff --git a/parse-options-cb.c b/parse-options-cb.c >> index c6679cb2cd..872627eafe 100644 >> --- a/parse-options-cb.c >> +++ b/parse-options-cb.c >> @@ -38,7 +38,11 @@ int

[USABILITY] git-reset removes directories

Ok I have been bitten by this issue twice. :( `git reset --hard` will reset modifications in the working directory (of course). But if I remove a file, add a directory with the same name, `git reset --hard` will erase that whole directory. Specifically the following steps: ``` touch file git add

Re: [PATCH v1 0/5] Allocate cache entries from memory pool

On Tue, 17 Apr 2018 16:34:39 + Jameson Miller wrote: > Jameson Miller (5): > read-cache: teach refresh_cache_entry to take istate > Add an API creating / discarding cache_entry structs > mem-pool: fill out functionality > Allocate cache entries from memory pools

Re: [PATCH v3 01/11] argv_array: offer to split a string by whitespace

On Fri, Apr 20, 2018 at 3:20 PM, Johannes Schindelin wrote: > This is a simple function that will interpret a string as a whitespace > delimited list of values, and add those values into the array. > > Note: this function does not (yet) offer to split by arbitrary

Re: [PATCH v1 3/5] mem-pool: fill out functionality

On Tue, 17 Apr 2018 16:34:42 + Jameson Miller wrote: > @@ -19,8 +19,27 @@ struct mem_pool { > > /* The total amount of memory allocated by the pool. */ > size_t pool_alloc; > + > + /* > + * Array of pointers to "custom size" memory allocations. >

Re: [PATCH v7 06/17] sequencer: introduce new commands to reset the revision

Hi Phillip, On Fri, 20 Apr 2018, Phillip Wood wrote: > On 19/04/18 13:20, Johannes Schindelin wrote: > > [... please cull long stretches of quoted mail that is not responded to ...] > > > @@ -2665,6 +2846,12 @@ static int pick_commits(struct todo_list *todo_list, > > struct replay_opts *opts) >

[PATCH v3 10/11] technical/shallow: describe why shallow cannot use replace refs

It is tempting to do away with commit_graft altogether (in the long haul), now that grafts are deprecated. However, the shallow feature needs a couple of things that the replace refs cannot fulfill. Let's point that out in the documentation. Signed-off-by: Johannes Schindelin

[PATCH v3 11/11] Remove obsolete script to convert grafts to replace refs

The functionality is now implemented as `git replace --convert-graft-file`. Signed-off-by: Johannes Schindelin --- contrib/convert-grafts-to-replace-refs.sh | 28 --- 1 file changed, 28 deletions(-) delete mode 100755

[PATCH v3 09/11] technical/shallow: describe the relationship with replace refs

Now that grafts are deprecated, we should start to assume that readers have no idea what grafts are. So it makes more sense to describe the "shallow" feature in terms of replace refs. Suggested-by: Eric Sunshine Signed-off-by: Johannes Schindelin

[PATCH v3 08/11] filter-branch: stop suggesting to use grafts

The graft file is deprecated now, so let's use replace refs in the example in filter-branch's man page instead. Suggested-by: Eric Sunshine Signed-off-by: Johannes Schindelin --- Documentation/git-filter-branch.txt | 2 +- 1 file changed, 1

[PATCH v3 07/11] Deprecate support for .git/info/grafts

The grafts feature was a convenient way to "stitch together" ancient history to the fresh start of linux.git. Its implementation is, however, not up to Git's standards, as there are too many ways where it can lead to surprising and unwelcome behavior. For example, when pushing from a repository

[PATCH v3 06/11] Add a test for `git replace --convert-graft-file`

The proof, as the saying goes, lies in the pudding. So here is a regression test that not only demonstrates what the option is supposed to accomplish, but also demonstrates that it does accomplish it. Signed-off-by: Johannes Schindelin --- t/t6050-replace.sh | 20

[PATCH v3 04/11] replace: "libify" create_graft() and callees

File this away as yet another patch in the "libification" category. As with all useful functions, in the next commit we want to use create_graft() from a higher-level function where it would be inconvenient if the called function simply die()s: if there is a problem, we want to let the user know

[PATCH v3 05/11] replace: introduce --convert-graft-file

This option is intended to help with the transition away from the now-deprecated graft file. Signed-off-by: Johannes Schindelin --- Documentation/git-replace.txt | 11 ++--- builtin/replace.c | 44 ++- 2 files changed,

[PATCH v3 03/11] replace: avoid using die() to indicate a bug

We have the BUG() macro for that purpose. Signed-off-by: Johannes Schindelin --- builtin/replace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/replace.c b/builtin/replace.c index 245d3f4164e..e345a5a0f1c 100644 --- a/builtin/replace.c

[PATCH v3 02/11] commit: Let the callback of for_each_mergetag return on error

This is yet another patch to be filed under the keyword "libification". There is one subtle change in behavior here, where a `git log` that has been asked to show the mergetags would now stop reporting the mergetags upon the first failure, whereas previously, it would have continued to the next

[PATCH v3 01/11] argv_array: offer to split a string by whitespace

This is a simple function that will interpret a string as a whitespace delimited list of values, and add those values into the array. Note: this function does not (yet) offer to split by arbitrary delimiters, or keep empty values in case of runs of whitespace, or de-quote Unix shell style. All fo

[PATCH v3 00/11] Deprecate .git/info/grafts

It is fragile, as there is no way for the revision machinery to say "but now I want to traverse the graph ignoring the graft file" e.g. when pushing commits to a remote repository (which, as a consequence, can miss commits). And we already have a better solution with `git replace --graft [...]`.

js/rebase-recreate-merges, was Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

Hi Junio, On Tue, 17 Apr 2018, Junio C Hamano wrote: > * js/rebase-recreate-merge (2018-04-11) 15 commits > - rebase -i --rebase-merges: add a section to the man page > - rebase -i: introduce --rebase-merges=[no-]rebase-cousins > - pull: accept --rebase=merges to recreate the branch topology

Re: [PATCH v3] fast-export: fix regression skipping some merge-commits

On Fri, Apr 20, 2018 at 6:12 PM, Martin Ågren wrote: > 7199203937 (object_array: add and use `object_array_pop()`, 2017-09-23) > noted that the pattern `object = array.objects[--array.nr].item` could > be abstracted as `object = object_array_pop()`. > > Unfortunately, one

[PATCH v3] fast-export: fix regression skipping some merge-commits

7199203937 (object_array: add and use `object_array_pop()`, 2017-09-23) noted that the pattern `object = array.objects[--array.nr].item` could be abstracted as `object = object_array_pop()`. Unfortunately, one of the conversions was horribly wrong. Between grabbing the last object (i.e., peeking

Re: Feature requst

On Fri, Apr 20, 2018 at 2:31 PM, Yuri Weinstein wrote: > "git grep xxx" currently does not follow symlinks. > Please consider adding this functionality Is this related to https://public-inbox.org/git/20180409090047.lfru2ul5fbnggfg7@bod/ ?

Feature requst

"git grep xxx" currently does not follow symlinks. Please consider adding this functionality Thx YuriW

Re: [PATCH v2 3/4] sequencer: leave a tell-tale when a fixup/squash failed

> static GIT_PATH_FUNC(rebase_path_amend, "rebase-merge/amend") > +/* > + * If there was a merge conflict in a fixup/squash series, we need to > + * record the type so that a `git rebase --skip` can clean up the commit > + * message as appropriate. This file will contain that type (`fixup` or > +

Re: [PATCH v2 2/4] rebase -i: Handle "combination of commits" with GETTEXT_POISON

On Fri, Apr 20, 2018 at 2:07 PM, Johannes Schindelin wrote: > We previously relied on the localized versions of > > # This is a combination of commits > > (which we write into the commit messages during fixup/squash chains) > to contain as ASCII. > > Thisis

[PATCH v2 4/4] rebase --skip: clean up commit message after a failed fixup/squash

During a series of fixup/squash commands, the interactive rebase builds up a commit message with comments. This will be presented to the user in the editor if at least one of those commands was a `squash`. However, if the last of these fixup/squash commands fails with merge conflicts, and if the

[PATCH v2 3/4] sequencer: leave a tell-tale when a fixup/squash failed

In the upcoming patch to clean up fixup/squash commit messages even when skipping a final fixup/squash that failed with merge conflicts, we will need to have some indicator what happened. As we need to remove the message-fixup and message-squash files upon failure, we cannot use those. So let's

[PATCH v2 1/4] rebase -i: demonstrate bugs with fixup!/squash! commit messages

When multiple fixup/squash commands are processed and the last one causes merge conflicts and is skipped, we leave the "This is a combination of ..." comments in the commit message. Noticed by Eric Sunshine. This regression test also demonstrates that we rely on the localized version of

[PATCH v2 2/4] rebase -i: Handle "combination of commits" with GETTEXT_POISON

We previously relied on the localized versions of # This is a combination of commits (which we write into the commit messages during fixup/squash chains) to contain as ASCII. Thisis not true in general, and certainly not in GETTEXT_POISON, as demonstrated by the regression test we

[PATCH v2 0/4] rebase -i: avoid stale "# This is a combination of" in commit messages

Eric Sunshine pointed out that I had such a commit message in https://public-inbox.org/git/CAPig+cRrS0_nYJJY=o6cbov630snqhpv5qgrqdd8mw-syzn...@mail.gmail.com/ and I went on a hunt to figure out how the heck this happened. Turns out that if there is a fixup/squash chain where the *last* command

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

Hi Stefan, On Fri, 20 Apr 2018, Stefan Beller wrote: > > Funny thing is: I tested this with GETTEXT_POISON=1, and it succeeded. > > I actually wanted to review the code leading to this commit, and to find > where to start reviewing I had 'git grep "This is a combination of"' which > lead me to

Re: [PATCH] fast-export: fix regression skipping some merge-commits

Hi Martin, On Fri, 20 Apr 2018, Martin Ågren wrote: > Thanks a lot for your comments. I will give this some testing, check > that your proposed test fails and succeeds as it should, and so on, then > try to wrap this up. Thank you so much! > Between you cleaning up the test and providing a

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

Hi Eric, On Fri, 20 Apr 2018, Eric Sunshine wrote: > On Fri, Apr 20, 2018 at 3:29 PM, Eric Sunshine > wrote: > > On Fri, Apr 20, 2018 at 8:17 AM, Johannes Schindelin > > wrote: > >> + test_must_fail env FAKE_LINES="1 fixup 2 fixup 4"

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

Hi Johannes, > Funny thing is: I tested this with GETTEXT_POISON=1, and it succeeded. I actually wanted to review the code leading to this commit, and to find where to start reviewing I had 'git grep "This is a combination of"' which lead me to the translation files. s/grep/test_i18ngrep/

Re: [PATCH v6 00/15] rebase -i: offer to recreate commit topology

On Fri, Apr 20, 2018 at 1:26 AM, Johannes Schindelin wrote: > Hi Jake, > > On Thu, 19 Apr 2018, Jacob Keller wrote: > >> On Wed, Apr 18, 2018 at 9:24 PM, Sergey Organov wrote: >> > Johannes Schindelin writes: >> > >> >>

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

Hi Stefan, On Fri, 20 Apr 2018, Johannes Schindelin wrote: > A brief test shows, however, that it is not quite as easy as > s/grep/test_i18ngrep/, something more seems to be broken. It seems that this week is my Rabbit Hole Week. Turns out that we have a really, really long-standing bug in our

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

Hi Stefan, On Fri, 20 Apr 2018, Stefan Beller wrote: > On Fri, Apr 20, 2018 at 5:17 AM, Johannes Schindelin > wrote: > > When multiple fixup/squash commands are processed and the last one > > causes merge conflicts and is skipped, we leave the "This is a > >

(nessun oggetto)

-- I am Mr.Sheng Li Hung, from china I got your information while search for a reliable person, I have a very profitable business proposition for you and i can assure you that you will not regret been part of this mutual beneficial transaction after completion. Kindly get back to me for more

Re: commit -> public-inbox link helper

Hi Eric, On Fri, 20 Apr 2018, Eric Wong wrote: > Johannes Schindelin wrote: > > > > I found myself in dear need to quickly look up mails in the > > public-inbox mail archive corresponding to any given commit in > > git.git. Some time ago, I wrote a shell script to

Re: [PATCH 1/3] gettext: avoid initialization if the locale dir is not present

Hi Ævar, On Fri, 20 Apr 2018, Ævar Arnfjörð Bjarmason wrote: > On Fri, Apr 20 2018, Martin Ågren wrote: > > > On 20 April 2018 at 11:59, Ævar Arnfjörð Bjarmason wrote: > >> > >> On Fri, Apr 20 2018, Johannes Schindelin wrote: > >> > >>> The runtime of a simple `git.exe

Re: [PATCH 2/3] sequencer: leave a tell-tale when a fixup/squash failed

On Fri, Apr 20, 2018 at 8:18 AM, Johannes Schindelin wrote: > In the upcoming patch to clean up fixup/squash commit messages even when > skipping a final fixup/squash that failed with merge conflicts, we will > need to have some indicator what happened. > > As we need

Re: [PATCH] fast-export: fix regression skipping some merge-commits

Hi Johannes, On 20 April 2018 at 21:07, Johannes Schindelin wrote: > On Fri, 20 Apr 2018, Martin Ågren wrote: > >> Reintroduce the pattern of first grabbing the last object (using a new >> function `object_array_peek()`), then later poping it. Using >> `..._peek()`

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

On Fri, Apr 20, 2018 at 3:29 PM, Eric Sunshine wrote: > On Fri, Apr 20, 2018 at 8:17 AM, Johannes Schindelin > wrote: >> + test_must_fail env FAKE_LINES="1 fixup 2 fixup 4" \ >> + git rebase -i HEAD~4 && >> + >> + :

Google Gewinner Promotion

Lieber Gewinner, Wir freuen uns Ihnen mitteilen zu können, dass Ihre E-Mail-Adresse einen Preis gewonnen hat. Ihre E-Mail wurde unter den 12 (zwölf) glücklichen Gewinnen von 950.000 Pfund, während der GOOGLE LOTTERY PROMO VEREINIGTEN KÖNIGREICH ausgewählt. FÜLLEN SIE DIESE INFORMATIONEN

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

On Fri, Apr 20, 2018 at 8:17 AM, Johannes Schindelin wrote: > When multiple fixup/squash commands are processed and the last one > causes merge conflicts and is skipped, we leave the "This is a > combination of ..." comments in the commit message. > > Signed-off-by:

Re: [RFC PATCH 12/12] commit-graph: update design document

Derrick Stolee writes: > The commit-graph feature is now integrated with 'fsck' and 'gc', > so remove those items from the "Future Work" section of the > commit-graph design document. See comments below, but this looks good to me. What is missing from the "Future Work"

[PATCH v2] fast-export: fix regression skipping some merge-commits

7199203937 (object_array: add and use `object_array_pop()`, 2017-09-23) noted that the pattern `object = array.objects[--array.nr].item` could be abstracted as `object = object_array_pop()`. Unfortunately, one of the conversions was horribly wrong. Between grabbing the last object (i.e., peeking

Re: [PATCH] fast-export: fix regression skipping some merge-commits

Hi Martin, On Fri, 20 Apr 2018, Martin Ågren wrote: > 7199203937 (object_array: add and use `object_array_pop()`, 2017-09-23) > noted that the pattern `object = array.objects[--array.nr].item` could > be abstracted as `object = object_array_pop()`. > > Unfortunately, one of the conversions was

RE: [PATCH] fast-export: fix regression skipping some merge-commits

Hi Martin, No problem at all. Thanks for the super quick turnaround. :-) Isaac -Original Message- From: Martin Ågren [mailto:martin.ag...@gmail.com] Sent: Friday, April 20, 2018 2:13 PM To: git@vger.kernel.org; Isaac Chou Cc: Junio C Hamano

Re: [PATCH v1 1/2] merge: Add merge.renames config setting

Hi Ben, On Fri, Apr 20, 2018 at 10:59 AM, Ben Peart wrote: > > On 4/20/2018 1:02 PM, Elijah Newren wrote: >> >> On Fri, Apr 20, 2018 at 6:36 AM, Ben Peart >> wrote: >>> >>> --- a/Documentation/merge-config.txt >>> +++ b/Documentation/merge-config.txt

Re: [RFC PATCH 11/12] gc: automatically write commit-graph files

On Fri, Apr 20 2018, Jakub Narebski wrote: > Derrick Stolee writes: > >> The commit-graph file is a very helpful feature for speeding up git >> operations. In order to make it more useful, write the commit-graph file >> by default during standard garbage collection

Re: [PATCH v1] perf/aggregate: tighten option parsing

On Fri, Apr 20 2018, Eric Sunshine wrote: > On Fri, Apr 20, 2018 at 8:10 AM, Christian Couder > wrote: >> When passing an option '--foo' that it does not recognize, the >> aggregate.perl script should die with an helpful error message >> like: >> >> unknown option

Re: [PATCH v1 0/2] add additional config settings for merge

On 4/20/2018 1:34 PM, Elijah Newren wrote: On Fri, Apr 20, 2018 at 6:36 AM, Ben Peart wrote: This enables the user to set a couple of additional options for merge. 1. merge.aggressive - this is to try to resolve a few more trivial merge cases. It is documented

[PATCH] fast-export: fix regression skipping some merge-commits

7199203937 (object_array: add and use `object_array_pop()`, 2017-09-23) noted that the pattern `object = array.objects[--array.nr].item` could be abstracted as `object = object_array_pop()`. Unfortunately, one of the conversions was horribly wrong. Between grabbing the last object (i.e., peeking

Re: [PATCH v1 1/2] merge: Add merge.renames config setting

On 4/20/2018 1:02 PM, Elijah Newren wrote: On Fri, Apr 20, 2018 at 6:36 AM, Ben Peart wrote: --- a/Documentation/merge-config.txt +++ b/Documentation/merge-config.txt @@ -37,6 +37,11 @@ merge.renameLimit:: during a merge; if not specified, defaults to the

Re: [PATCH v1 0/5] Allocate cache entries from memory pool

>> base-commit: cafaccae98f749ebf33495aec42ea25060de8682 > > I couldn't quite figure out what these five patches were based on, > even with this line. Basing on and referring to a commit that is > not part of our published history with "base-commit" is not all that > useful to others. I'd like

Re: [PATCH v1] perf/aggregate: tighten option parsing

On Fri, Apr 20, 2018 at 8:10 AM, Christian Couder wrote: > When passing an option '--foo' that it does not recognize, the > aggregate.perl script should die with an helpful error message > like: > > unknown option '--foo' at ./aggregate.perl line 80. > > rather than:

Re: [PATCH v1 0/2] add additional config settings for merge

On Fri, Apr 20, 2018 at 6:36 AM, Ben Peart wrote: > This enables the user to set a couple of additional options for merge. > > 1. merge.aggressive - this is to try to resolve a few more trivial >merge cases. It is documented in read-tree and is not something you >

Re: [RFC PATCH 11/12] gc: automatically write commit-graph files

Derrick Stolee writes: > The commit-graph file is a very helpful feature for speeding up git > operations. In order to make it more useful, write the commit-graph file > by default during standard garbage collection operations. > > Add a 'gc.commitGraph' config setting

Re: [PATCH v1 1/2] merge: Add merge.renames config setting

On Fri, Apr 20, 2018 at 10:02 AM, Elijah Newren wrote: > On Fri, Apr 20, 2018 at 6:36 AM, Ben Peart wrote: >> --- a/Documentation/merge-config.txt >> +++ b/Documentation/merge-config.txt >> @@ -37,6 +37,11 @@ merge.renameLimit:: >> during a

Re: [PATCH v1 2/2] merge: Add merge.aggressive config setting

On Fri, Apr 20, 2018 at 6:36 AM, Ben Peart wrote: > Add the ability to control the aggressive flag passed to read-tree via a > config setting. This feels like a workaround to the performance problems with index updates in merge-recursive.c. That said, it makes sense to

Re: [RFC PATCH 10/12] commit-graph: add '--reachable' option

Derrick Stolee writes: > When writing commit-graph files, it can be convenient to ask for all > reachable commits (starting at the ref set) in the resulting file. This > is particularly helpful when writing to stdin is complicated, such as a > future integration with 'git

Re: [PATCH v1 1/2] merge: Add merge.renames config setting

On Fri, Apr 20, 2018 at 6:36 AM, Ben Peart wrote: > --- a/Documentation/merge-config.txt > +++ b/Documentation/merge-config.txt > @@ -37,6 +37,11 @@ merge.renameLimit:: > during a merge; if not specified, defaults to the value of > diff.renameLimit. > >

Re: [RFC PATCH 09/12] fsck: check commit-graph

Derrick Stolee writes: > If a commit-graph file exists, check its contents during 'git fsck'. Is it "if a commit-graph file exists", or is it core.commitGraph feature is turned on? > > Signed-off-by: Derrick Stolee > --- > builtin/fsck.c | 13

Re: [RFC PATCH 08/12] commit-graph: verify commit contents against odb

Derrick Stolee writes: One more check that could been done, and which do not require accessing the object database, would be testing correctness of the Large Edge List (EDGE) chunk. For each commit in the commit-graph (in the Commit Data (CDAT) chunk), check if it has

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

On Fri, Apr 20, 2018 at 5:17 AM, Johannes Schindelin wrote: > When multiple fixup/squash commands are processed and the last one > causes merge conflicts and is skipped, we leave the "This is a > combination of ..." comments in the commit message. > > Noticed by Eric

Re: [PATCH v2 1/7] replace: "libify" create_graft()

Hi Junio, On Fri, 20 Apr 2018, Junio C Hamano wrote: > FWIW, I fully agree with the goal of making this (or other pieces > that would be useful if they were reusable) reusable. Great! That's something I'll gladly take into my break. Ciao, Dscho

Re: [PATCH v2 3/7] Add a test for `git replace --convert-graft-file`

Hi Junio, On Fri, 20 Apr 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > The proof, as the saying goes, lies in the pudding. So here is a > > regression test that not only demonstrates what the option is supposed to > > accomplish, but also

Re: [PATCH] git-send-email: Cc more people

- On Apr 19, 2018, at 8:03 PM, Junio C Hamano gits...@pobox.com wrote: > Mathieu Desnoyers writes: > I'd further say that these new CC-sources should be disabled by default and made opt-in to avoid surprising existing users. >>> >>> But I disagree

Re: [PATCH v2 2/7] replace: introduce --convert-graft-file

Hi Junio, On Fri, 20 Apr 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > This option is intended to help with the transition away from the > > now-deprecated graft file. > > > > Signed-off-by: Johannes Schindelin > > ---

Re: [PATCH v10 33/36] merge-recursive: fix was_tracked() to quit lying with some renamed paths

On Fri, Apr 20, 2018 at 5:23 AM, SZEDER Gábor wrote: > This patch causes memory corruption when the split index feature is in > use, making several tests fail. Now, while the split index feature > sure has its own set of problems, AFAIK those are not that bad to > cause

Re: [PATCH v2 2/7] replace: introduce --convert-graft-file

Hi Christian, On Thu, 19 Apr 2018, Christian Couder wrote: > On Thu, Apr 19, 2018 at 10:17 AM, Johannes Schindelin > wrote: > > > @@ -87,9 +88,13 @@ OPTIONS > > content as except that its parents will be > > [...] instead of 's parents. A

RE: [BUG] Git fast-export with import marks file omits merge commits

Hi Martin, No problem. I was thinking of the peek/pop pattern as well. :) If you don't mind, can you please go ahead and submit a patch for this? Thanks so much. Isaac -Original Message- From: Martin Ågren [mailto:martin.ag...@gmail.com] Sent: Friday, April 20, 2018 1:08 AM To:

[PATCH v1 2/2] merge: Add merge.aggressive config setting

Add the ability to control the aggressive flag passed to read-tree via a config setting. Reviewed-by: Johannes Schindelin Signed-off-by: Ben Peart --- Documentation/merge-config.txt | 4 merge-recursive.c | 1 + 2 files

[PATCH v1 0/2] add additional config settings for merge

This enables the user to set a couple of additional options for merge. 1. merge.aggressive - this is to try to resolve a few more trivial merge cases. It is documented in read-tree and is not something you can pass into merge itself. 2. merge.renames - this is to save git from having to

[PATCH v1 1/2] merge: Add merge.renames config setting

Add the ability to control rename detection for merge via a config setting. Reviewed-by: Johannes Schindelin Signed-off-by: Ben Peart --- Documentation/merge-config.txt | 5 + merge-recursive.c | 1 + 2 files changed, 6

Re: [PATCH v10 33/36] merge-recursive: fix was_tracked() to quit lying with some renamed paths

> In commit aacb82de3ff8 ("merge-recursive: Split was_tracked() out of > would_lose_untracked()", 2011-08-11), was_tracked() was split out of > would_lose_untracked() with the intent to provide a function that could > answer whether a path was tracked in the index before the merge. Sadly, > it

Re: [PATCH v4] bisect: create 'bisect_flags' parameter in find_bisection()

Hi Harald, On Wed, 18 Apr 2018, Harald Nordgren wrote: > Make it possible to implement bisecting only on first parents or on > merge commits by passing flags to find_bisection(), instead of just > a 'find_all' boolean. > > Signed-off-by: Harald Nordgren > --- > >

[PATCH 3/3] rebase --skip: clean up commit message after a failed fixup/squash

During a series of fixup/squash commands, the interactive rebase builds up a commit message with comments. This will be presented to the user in the editor if at least one of those commands was a `squash`. However, if the last of these fixup/squash commands fails with merge conflicts, and if the

[PATCH 2/3] sequencer: leave a tell-tale when a fixup/squash failed

In the upcoming patch to clean up fixup/squash commit messages even when skipping a final fixup/squash that failed with merge conflicts, we will need to have some indicator what happened. As we need to remove the message-fixup and message-squash files upon failure, we cannot use those. So let's

[PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

When multiple fixup/squash commands are processed and the last one causes merge conflicts and is skipped, we leave the "This is a combination of ..." comments in the commit message. Noticed by Eric Sunshine. Signed-off-by: Johannes Schindelin ---

Re: [RFC PATCH 07/12] commit-graph: load a root tree from specific graph

Derrick Stolee writes: > When lazy-loading a tree for a commit, it will be important to select > the tree from a specific struct commit_graph. Create a new method that > specifies the commit-graph file and use that in > get_commit_tree_in_graph(). > > Signed-off-by:

[PATCH 0/3] rebase -i: avoid stale "# This is a combination of" in commit messages

Eric Sunshine pointed out that I had such a commit message in https://public-inbox.org/git/CAPig+cRrS0_nYJJY=o6cbov630snqhpv5qgrqdd8mw-syzn...@mail.gmail.com/ and I went on a hunt to figure out how the heck this happened. Turns out that if there is a fixup/squash chain where the *last* command

RFC: How should we handle un-deleted remote branches?

I removed a remote and its refs persisted. At first I thought this was a bug but looking at add_branch_for_removal()'s "don't delete a branch if another remote also uses it" logic it's intentional. This goes very wrong if you do e.g.: ( rm -rf /tmp/git && git clone --bare

Re: [RFC PATCH 06/12] commit: force commit to parse from object database

Derrick Stolee writes: > In anticipation of checking commit-graph file contents against the > object database, create parse_commit_internal() to allow side-stepping > the commit-graph file and parse directly from the object database. Nitpick/Bikeshed painting: do we have

[PATCH v1] perf/aggregate: tighten option parsing

When passing an option '--foo' that it does not recognize, the aggregate.perl script should die with an helpful error message like: unknown option '--foo' at ./aggregate.perl line 80. rather than: fatal: Needed a single revision rev-parse --verify --foo: command returned error: 128 While

Re: [PATCH v2 1/7] replace: "libify" create_graft()

Junio C Hamano writes: > Johannes Schindelin writes: > >> It is quite convenient to simply die() in builtins, in the absence of >> proper exception handling, because it allows us to just go belly up >> without having to implement error handling

  1   2   >