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

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

[Nicholas Guriev]

Perceive simple "git worktree" without a subcommand as "git worktree list"
for consistency with "git submodule" that already can work in such a way.

Signed-off-by: Nicholas Guriev <guriev-ns@ya.ru>
---
 builtin/worktree.c       |  4 ++--
 t/t2402-worktree-list.sh | 12 ++++++++++++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/builtin/worktree.c b/builtin/worktree.c
index d99db356..ad949eb5 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -960,10 +960,10 @@ int cmd_worktree(int ac, const char **av, const char *prefix)
 
 	git_config(git_worktree_config, NULL);
 
-	if (ac < 2)
-		usage_with_options(worktree_usage, options);
 	if (!prefix)
 		prefix = "";
+	if (ac < 2 || av[1][0] == '-')
+		return list(ac, av, prefix);
 	if (!strcmp(av[1], "add"))
 		return add(ac - 1, av + 1, prefix);
 	if (!strcmp(av[1], "prune"))
diff --git a/t/t2402-worktree-list.sh b/t/t2402-worktree-list.sh
index 52585ec2..e53bafa3 100755
--- a/t/t2402-worktree-list.sh
+++ b/t/t2402-worktree-list.sh
@@ -157,4 +157,16 @@ test_expect_success 'worktree path when called in .git directory' '
 	test_cmp list1 list2
 '
 
+test_expect_success '"list" is the default command' '
+	git worktree >out1 &&
+	git worktree list >out2 &&
+	test_cmp out1 out2
+'
+
+test_expect_success 'options are passed to default command' '
+	git worktree --porcelain >out1 &&
+	git worktree list --porcelain >out2 &&
+	test_cmp out1 out2
+'
+
 test_done
-- 
2.25.1

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

[Junio C Hamano]

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

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

[Eric Sunshine]

On Sat, Jun 13, 2020 at 12:36 PM Junio C Hamano <gitster@pobox.com> wrote:
> 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.