RE: [PATCH v4 4/4] worktree: make add <path> dwim

["Randall S. Becker" <rsbecker@nexbridge.com>]

On November 25, 2017 3:06 PM Thomas Gummerer wrote:
<big snip>
>however we currently document one behaviour, which I would like to change
(I usually have branches
>without a / in that I want to look at) we currently document one behaviour,
which I'd like to change.  So 
>in that case we are a bit worried about backwards compatibility, and how
this will affect current users
>that have a certain expectation of how the command is supposed to work,
hence the discussion of
>whether to hide the new behaviour behind a flag or not.

>Either way, if we do put the behaviour behind a flag, I'll also add a
configuration variable, which can
>be set to enable the new behaviour so one doesn't have to type out the flag
all the time.

To be consistent with other commands, you could put path after -- and the
ambiguity with refs containing '/' goes away, as refs before the -- would
always be considered refs while after you have paths.

What I don't like is the current add syntax of:
git worktree add [-f] [--detach] [--checkout] [--lock] [-b <new-branch>]
<path> [<branch>]

where the path-spec precedes branch making things a bit icky. It might be
better to have an alternate syntax of:

git worktree add [-f] [--detach] [--checkout] [--lock] [-b <new-branch>]
<path> [<branch>]
git worktree add [-f] [--detach] [--checkout] [--lock] [-b <new-branch>]
[<branch>] -- <path>

But since we only have one path, that may be redundant. Just a thought, as
-- avoids a lot of interpretation evils. While we're here, I wonder whether
<branch> should be changed to <ref-spec> for more general use. Consider
release identifiers using tags, and using the tag instead of branch to
define commit on which the worktree is based.

Cheers,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(211288444200000000) 
-- In my real life, I talk too much.