Thomas Gummerer <t.gummerer@xxxxxxxxx> writes:
> I'm a bit torn about hiding his behind an additional flag in git
> worktree add or not. I would like to have the feature without the
> additional flag, but it might break some peoples expectations, so
> dunno.
Yeah, I agree with the sentiment. But what expectation would we be
breaking, I wonder (see below)?
At the conceptual level, it is even more unfortunate that "git
worktree --help" says this for "git worktree add <path> [<branch>]":
If `<branch>` is omitted and neither `-b` nor `-B` nor
`--detach` used, then, as a convenience, a new branch based at
HEAD is created automatically, as if `-b $(basename <path>)` was
specified.
which means that it already does a DWIM, namely "since you didn't
say what branch to create to track what other branch, we'll fork one
for you from the HEAD, and give a name to it". That may be a useful
DWIM for some existing users sometimes, and you may even find it
useful some of the time but not always. Different people mean
different things in different situations, and there is no single
definition for DWIMming that would fit all of them.
Which in turn means that the new variable name DWIM_NEW_BRANCH and
the new option name GUESS are way underspecified. You'd need to
name them after the "kind" of dwim; otherwise, not only the future
additions for new (third) kind of dwim would become cumbersome, but
readers of the code would be confused if they are about the existing
dwim (fork a new branch from HEAD and give it a name guessed by the
pathname) or your new dwim.
This also needs a documentation update. Unlike the existing DWIM,
it is totally unclear when you are dwimming in absence of which
option.
I am guessing that, when you do not have a branch "topic" but your
upstream does, saying
$ git worktree add ../a-new-worktree topic
would create "refs/heads/topic" to build on top of
"refs/remotes/origin/topic" just like "git checkout topic" would.
IOW, when fully spelled out:
$ git branch -t -b topic origin/topic
$ git worktree add ../a-new-worktree topic
is what your DWIM does? Am I following you correctly?
If so, as long as the new DWIM kicks in ONLY when "topic" does not
exist, I suspect that there is no backward compatibility worries.
The command line
$ git worktree add ../a-new-worktree topic
would just have failed because three was no 'topic' branch yet, no?
