Hi Duy, On Sun, 6 May 2018, Duy Nguyen wrote: > On Sun, May 6, 2018 at 6:53 AM, Jacob Keller <jacob.keller@xxxxxxxxx> wrote: > > On Sat, May 5, 2018 at 6:05 PM, Igor Djordjevic > > <igor.d.djordjevic@xxxxxxxxx> wrote: > >> > >> 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 for `tbdiff`. > >>> > > >>> > 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 the `branch-diff` part but > >>> not the options and other arguments. > >>> > >>> This of itself may already be slightly disruptive for well-trained > >>> fingers that assume that `git bra<TAB>ori<TAB>mas<TAB>` would expand to > >>> `git branch origin/master`, as we now no longer automatically append a > >>> space after completing `git branch`: this is now ambiguous. > >>> > >>> > It feels really petty complaining about the name, but I just want > >>> > to raise the point, since it will never be easier to change than > >>> > right now. > >>> > >>> I do hear you. Especially since I hate `git cherry` every single > >>> time that I try to tab-complete `git cherry-pick`. > >>> > >>> > (And no, I don't really have another name in mind; I'm just > >>> > wondering if "subset" names like this might be a mild annoyance in > >>> > the long run). > >>> > >>> They totally are, and if you can come up with a better name, I am > >>> really interested in changing it before this hits `next`, even. > >> > >> I gave this just a quick glance so might be I`m missing something > >> obvious or otherwise well-known here, bur why not `diff-branch` instead? > >> > >> From user interface perspective, I would (personally) rather expect a > >> command that does "diff of branches" to belong to "diff family" of > >> commands (just operating on branches, instead of "branch" command > >> knowing to "diff itself"), and I see we already have `diff-files`, > >> `diff-index` and `diff-tree`, for what that`s worth. > >> > >> Heck, I might even expect something like `git diff --branch ...` to work, > >> but I guess that is yet a different matter :) > >> > >> Thanks, Buga > > > > I like diff-branch, though I suppose that also conflicts with diff too. > > How about interdiff? No. An interdiff is well defined as the diff you would get by first applying the first of two patches in reverse and then the second patch forward. In other words, it turns two revisions of a patch into the diff between the result of applying both revisions. I tried very hard to avoid using that term in my patch series (tbdiff used the term incorrectly: what it called an interdiff is a diff of two patches, where a patch is an author line followed by the commit message followed by the commit diff). Ciao, Dscho
