Hi Eric, On Sun, 6 May 2018, Eric Sunshine wrote: > On Sun, May 6, 2018 at 8:21 AM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > On Sun, 6 May 2018, Junio C Hamano wrote: > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > >> > 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? > >> > >> If tbdiff were "Thomas's branch diff", I would call this jbdiff ;-) > >> but I think the 't' in there stands for "topic", not "Thomas's". > >> How about "git topic-diff"? > > > > Or `git topic-branch-diff`? > > > > But then, we do not really use the term `topic branch` a lot in Git, *and* > > the operation in question is not really about showing differences between > > topic branches, but between revisions of topic branches. > > > > So far, the solution I like best is to use `git branch --diff <...>`, > > which also neatly side-steps the problem of cluttering the top-level > > command list (because tab completion). > > Let's, please, not fall into the trap of polluting git-branch with > utterly unrelated functionality, as has happened a few times with > other Git commands. Let's especially not do so merely for the sake of > tab-completion. git-branch is for branch management; it's not for > diff'ing. I totally disagree. `git branch` is *the* command to work with branches. Yes, you can manage branches. But you can also list them. And now you can also compare them. > Of the suggestions thus far, Junio's git-topic-diff seems the least > worse, and doesn't suffer from tab-completion problems. Except that this is too limited a view. Have you seen one of the more important tidbits in the cover letter, the one about Git for Windows' *branch thicket*? In this case, it is not *one* topic branch that we are talking about. And even worse: what this patch series introduces is not at all a feature to compare topic branches! Instead, it is a way to compare iterations of patch series, versions of topic branches, changes introduced into a topic branch by rebasing it, etc. And `git topic-diff` simply does not say this. It says something different, something that my patches cannot fulfill. > Building on Duy's suggestion: git-interdiff could be a superset of the > current git-branch-diff: > > # standard interdiff > git interdiff womp-v1 womp-v2 > # 'tbdiff'-like output > git interdiff --topic womp-v1 womp-v2 No, no, and no. An interdiff is an interdiff is an interdiff. See e.g. https://www.tutorialspoint.com/unix_commands/interdiff.htm for details. The operation introduced by this patch series, or for that matter tbdiff, *never ever* produced an interdiff. Get this "interdiff" label out of your mind immediately when you think about this here operation. One of my commit messages even talks about this, and says *why* we do not generate interdiffs: they are in general not even well-defined. Take my --rebase-merges patch series, for example. It is so long-running that at some stages, all I did was to resolve merge conflicts incurred from rebasing to `master`. That was literally all. Now, if you tried to produce an interdiff, you would *already fail in the first step*, as the previous overall diff does not apply in reverse on current `master`. Out of all the options so far, the one that I liked was `git branch --diff`. Seriously. I do not understand why you think that this is abusing the `git branch` command. It is no less abusing it than `git branch --edit-description`! And that is a *very good* command, and it is *very good* that it is an option to `git branch`. It makes a total lot of sense, I have never had to think "wait, in which Git command is this implemented already?" And I would expect the exact same thing to happen with `git branch --diff`. Ciao, Johannes
