Re: [PATCH v2 00/18] Add `branch-diff`, a `tbdiff` lookalike

Johannes Schindelin writes: > Johannes Schindelin (17): > Add a function to solve least-cost assignment problems > Add a new builtin: branch-diff Perhaps retitling these to hungarian: a function to solve least-cost assignment problems branch-diff: a new

Re: cherry-pick --no-commit does not work well with --continue in case of conflicts

Let's say master..feature has 2 commits: A and B. Then `git cherry-pick -n master..feature` should pick-up A and then B into the working directory and the index. If applying A leads to a conflict, then it stops on A, like here: >>> git cherry-pick -n master..feature >> error: could not apply

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On Sat, May 5, 2018 at 6:05 PM, Igor Djordjevic wrote: > Hi Dscho, > > On 05/05/2018 23:57, Johannes Schindelin wrote: >> >> > > This builtin does not do a whole lot so far, apart from showing a >> > > usage that is oddly similar to that of `git tbdiff`. And for a >>

Re: [PATCHv2] git-send-email: allow re-editing of message

Drew DeVault writes: > When shown the email summary, an opportunity is presented for the user > to edit the email as if they had specified --annotate. This also permits > them to edit it multiple times. > > Signed-off-by: Drew DeVault > Reviewed-by: Simon Ser

Re: [RFC PATCH] checkout: Force matching mtime between files

Jeff King writes: > The files in your checkout would all be consistent, but they might be > inconsistent with other files _not_ created by Git (e.g., one might be > saved in your editor). Now you may have introduced skew that cause > "make" to do the wrong thing, because your

Re: cherry-pick --no-commit does not work well with --continue in case of conflicts

Ilya Kantor writes: > Somewhy cherry-pick --no-commit does not work well with --continue. > > Let's say I'm copying changes w/o committing and get a conflict: > >> git cherry-pick -n master..feature > error: could not apply 2c11f12... Run work > > Then I fix the conflict, but

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Johannes Schindelin writes: > Hi Peff, > > On Sat, 5 May 2018, Jeff King wrote: > >> On Fri, May 04, 2018 at 05:34:32PM +0200, Johannes Schindelin wrote: >> >> > This builtin does not do a whole lot so far, apart from showing a usage >> > that is oddly similar to

Re: [PATCH v2 05/18] branch-diff: also show the diff between patches

Hi Johannes, On 04/05/2018 17:34, Johannes Schindelin wrote: > Just like tbdiff, we now show the diff between matching patches. This is > a "diff of two diffs", so it can be a bit daunting to read for the > beginner. > > And just like tbdiff, we now also accept the `--no-patches` option > (which

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Hi Dscho, On 05/05/2018 23:57, Johannes Schindelin wrote: > > > > This builtin does not do a whole lot so far, apart from showing a > > > usage that is oddly similar to that of `git tbdiff`. And for a > > > good reason: the next commits will turn `branch-diff` into a > > > full-blown replacement

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

I wrote: > Would it be possible and reasonable to teach 'git branch' to > call this as a subcommand, i.e. as 'git branch diff'? Then > the completion wouldn't offer git branch-diff. Of course right after I sent this, it occurred to me that 'git branch diff' would make mask the ability to create

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Hi Johannes, Johannes Schindelin wrote: > On Sat, 5 May 2018, Jeff King wrote: >> One minor point about the name: will it become annoying as a tab >> completion conflict with git-branch? > > I did mention this in the commit message of 18/18: > > Without this patch, we would only complete

Re: [PATCH v2 12/18] branch-diff: use color for the commit pairs

Hi Johannes, As many others have already said, thanks for this series! I've used tbdiff a bit over the years, but having a builtin will make it much more convenient (and the speed boost from a C implementation will be a very nice bonus). Johannes Schindelin wrote: > @@ -430,6 +451,8 @@ int

Re: [PATCH v2 13/18] color: provide inverted colors, too

Hi Peff, On Sat, 5 May 2018, Jeff King wrote: > On Fri, May 04, 2018 at 05:34:58PM +0200, Johannes Schindelin wrote: > > > For every regular color, there exists the inverted equivalent where > > background and foreground colors are exchanged. > > > > We will use this in the next commit to

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Hi Peff, On Sat, 5 May 2018, Jeff King wrote: > On Fri, May 04, 2018 at 05:34:32PM +0200, Johannes Schindelin wrote: > > > This builtin does not do a whole lot so far, apart from showing a usage > > that is oddly similar to that of `git tbdiff`. And for a good reason: > > the next commits will

Re: [PATCH v2 01/18] Add a function to solve least-cost assignment problems

Hi Peff, On Sat, 5 May 2018, Jeff King wrote: > On Fri, May 04, 2018 at 05:34:29PM +0200, Johannes Schindelin wrote: > > > The Jonker-Volgenant algorithm was implemented to answer questions such > > as: given two different versions of a topic branch (or iterations of a > > patch series), what

cherry-pick --no-commit does not work well with --continue in case of conflicts

Somewhy cherry-pick --no-commit does not work well with --continue. Let's say I'm copying changes w/o committing and get a conflict: > git cherry-pick -n master..feature error: could not apply 2c11f12... Run work Then I fix the conflict, but cherry-pick refuses to go on: > git add . > git

Re: [PATCH 02/18] Add a new builtin: branch-diff

Hi Elijah, On Fri, 4 May 2018, Elijah Newren wrote: > On Thu, May 3, 2018 at 11:40 PM, Johannes Schindelin > wrote: > > I actually have a hacky script to fixup commits in a patch series. It lets > > me stage part of the current changes, then figures out which of the

Re: [PATCH v2 00/18] Add `branch-diff`, a `tbdiff` lookalike

Hi Elijah, On Fri, 4 May 2018, Elijah Newren wrote: > On Fri, May 4, 2018 at 8:34 AM, Johannes Schindelin > wrote: > > The incredibly useful `git-tbdiff` tool to compare patch series (say, to see > > what changed between two iterations sent to the Git mailing list)

Re: [PATCH 02/18] Add a new builtin: branch-diff

Hi Ramsay, On Fri, 4 May 2018, Ramsay Jones wrote: > On 04/05/18 07:40, Johannes Schindelin wrote: > [snip] > > BTW I ran `make sparse` for the first time, and it spits out tons of > > stuff. And I notice that they are all non-fatal warnings, but so were the > > ones you pointed out above. This

Re: [PATCH v2 1/4] test-tool: help verifying BUG() code paths

Hi Duy, On Wed, 2 May 2018, Duy Nguyen wrote: > On Wed, May 2, 2018 at 11:38 AM, Johannes Schindelin > wrote: > > When we call BUG(), we signal via SIGABRT that something bad happened, > > dumping cores if so configured. In some setups these coredumps are > >

Re: [PATCH v2 0/6] Let the sequencer handle `git rebase -i --root`

Hi Stefan, On Fri, 4 May 2018, Stefan Beller wrote: > > Branch-diff vs v1: > > 1: 42db734a980 ! 1: 73398da7119 sequencer: learn about the special "fake > > root commit" handling > > @@ -54,40 +54,50 @@ > > return NULL; > >} > > > > ++/* Read author-script and return

Re: git update-ref fails to create reference. (bug)

Thanks Martin for the quick fix. On Fri, May 04, 2018 at 08:26:46PM +0200, Martin �gren wrote: > Anyway, that's not where I'm stuck... Regardless of how I try to write > tests (in t1400), they just pass beautifully even before this patch. I > might be able to look into that more on the weekend.

Re: [RFC PATCH] checkout: Force matching mtime between files

On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: > In order to avoid unnecessary cache mismatches, force a matching mtime > between all files created by a single checkout action. This seems to be > the best course of action. Matching mtimes do not trigger cache > updates. They

Re: [PATCH v2 13/18] color: provide inverted colors, too

On Fri, May 04, 2018 at 05:34:58PM +0200, Johannes Schindelin wrote: > For every regular color, there exists the inverted equivalent where > background and foreground colors are exchanged. > > We will use this in the next commit to allow inverting *just* the +/- > signs in a diff. There's a

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On Fri, May 04, 2018 at 05:34:32PM +0200, Johannes Schindelin wrote: > This builtin does not do a whole lot so far, apart from showing a usage > that is oddly similar to that of `git tbdiff`. And for a good reason: > the next commits will turn `branch-diff` into a full-blown replacement > for

Re: [PATCH v2 01/18] Add a function to solve least-cost assignment problems

On Fri, May 04, 2018 at 05:34:29PM +0200, Johannes Schindelin wrote: > The Jonker-Volgenant algorithm was implemented to answer questions such > as: given two different versions of a topic branch (or iterations of a > patch series), what is the best pairing of commits/patches between the >

Re: [PATCH] pack-objects: validation and documentation about unreachable options

On Sat, May 05, 2018 at 10:47:16AM +0200, Nguyễn Thái Ngọc Duy wrote: > These options are added in [1] [2] [3]. All these depend on running > rev-list internally which is normally true since they are always used > with "--all --objects" which implies --revs. But let's keep this > dependency

Re: [PATCH 1/2] Fix support for merge options.

On Sat, May 5, 2018 at 5:41 PM, wrote: > Christian wrote: >> >> It looks like git-reintegrate is not managed in Git but in this >> repository : >> >> https://github.com/felipec/git-reintegrate >> >> So could be a bit confusing to send those patches to the Git mailing >> list

Re: [PATCH 1/2] Fix support for merge options.

Christian wrote: > Hi Yann, > > On Sat, May 5, 2018 at 3:24 PM, Yann Dirson wrote: > > --- > > git-reintegrate | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/git-reintegrate b/git-reintegrate > > It looks like git-reintegrate is not

Re: [GSoC] Yet another blog series about the GSoC

Hi Pratik and Alban, On Sat, May 5, 2018 at 2:24 PM, Pratik Karki wrote: > On Sat, May 5, 2018 at 5:11 PM, Alban Gruin wrote: >> >> as my fellow students, I started a blog series about my GSoC project[1]. >> First, I wanted to post them directly

Re: [PATCH 1/2] Fix support for merge options.

Hi Yann, On Sat, May 5, 2018 at 3:24 PM, Yann Dirson wrote: > --- > git-reintegrate | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/git-reintegrate b/git-reintegrate It looks like git-reintegrate is not managed in Git but in this repository :

Re: [RFC] Other chunks for commit-graph, part 1 - Bloom filters, topo order, etc.

Ævar Arnfjörð Bjarmason writes: > On Fri, May 04 2018, Jakub Narebski wrote: > > (Just off-the cuff here and I'm surely about to be corrected by > Derrick...) > >> * What to do about merge commits, and octopus merges in particular? >> Should Bloom filter be stored for each of

[PATCH 1/2] Fix support for merge options.

--- git-reintegrate | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/git-reintegrate b/git-reintegrate index a1c17d2..da45239 100755 --- a/git-reintegrate +++ b/git-reintegrate @@ -338,7 +338,7 @@ class Integration def finalize_command(cmd, args, message) begin

[PATCH 2/2] Fix wrong merge-base invocation preventing detection of up-to-date branches.

--- git-reintegrate | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-reintegrate b/git-reintegrate index da45239..a6e3cff 100755 --- a/git-reintegrate +++ b/git-reintegrate @@ -581,7 +581,7 @@ def status_merge(branch_to_merge = nil) elsif system(*%w[git merge-base

Re: [GSoC] Yet another blog series about the GSoC

On Sat, May 5, 2018 at 5:11 PM, Alban Gruin wrote: > Hi everybody, > > as my fellow students, I started a blog series about my GSoC project[1]. > First, I wanted to post them directly on the mailing list, but a blog > allows me to edit the content easily if needed. > > Any

[GSoC] Yet another blog series about the GSoC

Hi everybody, as my fellow students, I started a blog series about my GSoC project[1]. First, I wanted to post them directly on the mailing list, but a blog allows me to edit the content easily if needed. Any feedback is welcome! [1]

[PATCH] pack-objects: validation and documentation about unreachable options

These options are added in [1] [2] [3]. All these depend on running rev-list internally which is normally true since they are always used with "--all --objects" which implies --revs. But let's keep this dependency explicit. While at there, add documentation for them. These are mostly used

Re: [PATCH 2/2] builtin/grep.c: teach '-o', '--only-matching' to 'git-grep'

On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote: > Teach GNU grep(1)'s '-o' ('--only-matching') to 'git-grep'. This option > prints only the matching components of each line. It writes multiple > lines if more than one match exists on a given line. > > For example: > > $

Re: [PATCH 1/2] grep.c: extract show_line_header()

On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote: > Teach 'git-grep(1)' how to print a line header multiple times from > show_line() in preparation for it learning '--only-matching'. > > show_line_header() comprises of the code in show_line() executed in s/of// > order to

[PATCH] completion: fix misspelled config key aliasesfiletype

The correct name in git-send-email.perl is aliasfiletype [1]. There are actually two instances of this misspelling. The other was found and fixed in 6068ac8848 (completion: add missing configuration variables - 2010-12-20) [1] 994d6c66d3 (send-email: address expansion for common mailers -

Re: [PATCH 2/2] builtin/grep.c: teach '-o', '--only-matching' to 'git-grep'

On Sat, May 05 2018, Taylor Blau wrote: > +--o:: > +--only-matching:: > + Show only the matching part of the lines. > + Makes sense to steal GNU grep's description here: Print only the matched (non-empty) parts of a matching line, with each such part on a separate output line. > +

Re: [PATCH v4 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

On Sat, May 5, 2018 at 4:43 AM, Taylor Blau wrote: > Teach 'git-grep(1)' a new option, '--column', to show the column > number of the first match on a non-context line. Why? Or put it another way, what is this option used for? Only git-jump? (which should also be mentioned