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

From: Todd Zullinger <tmz@pobox.com>
Date: May 6, 2018, 00:25 UTC
Message-ID: <20180506002532.GS26695@zaya.teonanacatl.net>
In-Reply-To: <nycvar.QRO.7.76.6.1805052355190.77@tvgsbejvaqbjf.bet>

Hi Johannes,

Johannes Schindelin wrote:

Show 25 quoted lines

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

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.