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

[Thomas Gummerer <t.gummerer@gmail.com>]

On 11/25, Paul Smith wrote:
> On Sat, 2017-11-25 at 17:50 +0000, Thomas Gummerer wrote:
> > 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.