On 11/25, Paul Smith wrote:

On Sat, 2017-11-25 at 17:50 +0000, Thomas Gummerer wrote:

quoted

This would be the output in the new version:

     $ git worktree add ../bla
     Branch 'bla' set up to track remote branch 'bla' from 'origin'.
     Preparing ../bla (identifier bla)
     HEAD is now at 4aade43 bla

vs. the output without the changed behaviour:

     $ git worktree add ../bla
     Preparing ../bla (identifier bla)
     HEAD is now at 0f215c9 initial import

Of course that assumes that it's used directly, not in scripts, and
that users will actually read the output of the command when they
invoke it.  Maybe these are not safe assumptions to make though, and
we'd rather not have this on by default then.  As I mentioned
previously I would prefer having this as default, but I'm happy to
hide this behaviour behind a flag if we want to be more careful about
introducing this.  Dunno?

Speaking as a simple user, I find the current behavior of Git worktree
add very frustrating; I am constantly wanting to create worktrees for
other peoples' branches so I can look at the code there without messing
up my workspace, and it's really inconvenient to do that now.

Also, the current special handling of the directory name as a putative
branch name is not helpful for me because many of the branches I need
to examine use "/" as their separator.  I don't begrudge making that
feature more "DWIM" for those that can use it, but hopefully some help
is forthcoming for those who can't.

For example, I need to create a local worktree for the remote rel/1.0
branch... what do I do?

What I want to work is this:

    git worktree add ../1.0 rel/1.0

and have it create a worktree at ../1.0, then do the equivalent of "git
checkout rel/1.0" which includes setting up to track the remote branch.
 But of course this doesn't work at all; I get:

    fatal: invalid reference: rel/1.0

Personally I would think it odd to have to add an extra flag to get
what I would expect would be "normal" behavior (checkout).

But maybe that's just me.

This part is getting done in 3/4, and is definitely going to work
without an additional flag, so this is (hopefully) soon going to work
just as you want :)

This is less controversial because as you mentioned this currently
doesn't work at all, so there are no backwards compatibility worries.

For the other case of

    git worktree add ../foo

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.