Re: [PATCH v6 00/21] Add range-diff, a tbdiff lookalike
- From
Thomas Gummerer <t.gummerer@gmail.com>
- Date
- Aug 13, 2018, 20:47 UTC
- Message-ID
- <20180813204714.GI2734@hank.intra.tgummerer.com>
- In-Reply-To
- <nycvar.QRO.7.76.6.1808131337360.71@tvgsbejvaqbjf.bet>
On 08/13, Johannes Schindelin wrote:
Show 46 quoted lines
> Hi,
>
> On Mon, 13 Aug 2018, Johannes Schindelin via GitGitGadget wrote:
>
> > The incredibly useful git-tbdiff [https://github.com/trast/tbdiff] tool to
> > compare patch series (say, to see what changed between two iterations sent
> > to the Git mailing list) is slightly less useful for this developer due to
> > the fact that it requires the hungarian and numpy Python packages which are
> > for some reason really hard to build in MSYS2. So hard that I even had to
> > give up, because it was simply easier to re-implement the whole shebang as a
> > builtin command.
> >
> > The project at https://github.com/trast/tbdiff seems to be dormant, anyway.
> > Funny (and true) story: I looked at the open Pull Requests to see how active
> > that project is, only to find to my surprise that I had submitted one in
> > August 2015, and that it was still unanswered let alone merged.
> >
> > While at it, I forward-ported AEvar's patch to force --decorate=no because
> > git -p tbdiff would fail otherwise.
> >
> > Side note: I work on implementing range-diff not only to make life easier
> > for reviewers who have to suffer through v2, v3, ... of my patch series, but
> > also to verify my changes before submitting a new iteration. And also, maybe
> > even more importantly, I plan to use it to verify my merging-rebases of Git
> > for Windows (for which I previously used to redirect the
> > pre-rebase/post-rebase diffs vs upstream and then compare them using git
> > diff --no-index). And of course any interested person can see what changes
> > were necessary e.g. in the merging-rebase of Git for Windows onto v2.17.0 by
> > running a command like:
> >
> > base=^{/Start.the.merging-rebase}
> > tag=v2.17.0.windows.1
> > pre=$tag$base^2
> > git range-diff $pre$base..$pre $tag$base..$tag
> >
> > The command uses what it calls the "dual color mode" (can be disabled via
> > --no-dual-color) which helps identifying what actually changed: it prefixes
> > lines with a - (and red background) that correspond to the first commit
> > range, and with a + (and green background) that correspond to the second
> > range. The rest of the lines will be colored according to the original
> > diffs.
>
> Changes since v5:
>
> - Fixed the bug (introduced in v5) where a dashdash would not be handled
> appropriately.Thanks! I've read through all the patches (and the range-diff :)) again and played around a bit with the newest version, and I think this is ready for 'next'.
While playing around with it I did find one error message that reads slightly odd, but it's still understandable, so I'm not sure it's worth worrying about now (we can always improve it on top):
$ ./git range-diff -- js/range-diff-v4...HEADt
fatal: ambiguous argument 'HEADt..js/range-diff-v4': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
error: could not parse log for 'HEADt..js/range-diff-v4'> [...]