On 08/13, Johannes Schindelin wrote: > 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' > [...]
