Re: [PATCH] worktree: treat "list" as default command

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jun 14, 2020, 05:56 UTC
Message-ID: <CAPig+cRLkv=gd58Qm2MiKz2H74s3O1zoQ4GZ_cBE7QkbBCqN4A@mail.gmail.com>
In-Reply-To: <xmqqr1uizzwf.fsf@gitster.c.googlers.com>

On Sat, Jun 13, 2020 at 12:36 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

> Nicholas Guriev <guriev-ns@ya.ru> writes:
> > Perceive simple "git worktree" without a subcommand as "git worktree list"
> > for consistency with "git submodule" that already can work in such a way.
>
> "git branch" works the same way, and probably "git remote", too?
>
> "git config" doesn't work that way, though. Should it default to
> the list mode (rhetorical/tongue-in-cheek question---but it gives a
> hint for writing the justification to decide where to draw the line).

My knee-jerk reaction to this patch is not to accept such a change, though I can't fully articulate why I feel this way.

One concrete reason I'm not enthused about this change is, as Junio notes, there is no consensus even among Git commands, as to what action should be taken when not specified explicitly. Although bare "git branch" is interpreted as "git branch list", bare "git stash" is _not_ interpreted as "git stash list", but instead as "git stash push". It's possible to imagine someone familiar with "git stash" coming along and expecting bare "git worktree" to mean "git worktree add".

I also have a vague recollection from past mailing list discussions that people eventually consider it flawed UI design for a command to perform some default action when none is requested explicitly. Bare "git stash" is one such example which comes to mind as being considered poor UI design. (It's possible that this recollection is incorrect; I haven't bothered trying to dig up any past discussions.)

Finally, not having a default action for bare "git worktree" was a deliberate design decision, probably (at least in part) motivated by the above considerations. So, I'm hesitant about accepting such a change without stronger justification.

The patch itself looks reasonable -- based upon a superficial scan -- although I'd probably combine the two new tests (though that's subjective). To be accepted, however (assuming people are convinced it is a worthwhile change), it would almost certainly need to include an update to Documentation/git-worktree.txt.