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

Hi Johannes,

Johannes Schindelin wrote:

On Sat, 5 May 2018, Jeff King wrote:

quoted

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.

quoted

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`.

quoted

(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.

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.

Users could still call it directly if they wanted, though
I'd tend to think that should be discouraged and have it
treated as an implementation detail that it's a separate
binary.

We have a number of commands which take subcommands this way
(bundle, bisect, notes, submodule, and stash come to mind).
I don't know if any are used with and without a subcommand,
but it doesn't seem too strange from a UI point of view, to
me.

(I don't know if it's coincidental that of the existing
commands I noted above, 3 of the 5 are currently implemented
as shell scripts.  But they've all seen at least some work
toward converting them to C, I believe).

The idea might be gross and/or unreasonable from an
implementation or UI view.  I'm not sure, but I thought I
would toss the idea out.

This wouldn't work for git cherry{,-pick} where you wouldn't
consider 'git cherry pick' as related to 'git cherry'
though.

We also have this with git show{,-branch} and some others.
It's a mild annoyance, but muscle memory adapts eventually.

-- 
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A budget is just a method of worrying before you spend money, as well
as afterward.