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.
