Re: [PATCH v4 4/4] worktree: make add <path> dwim
- From
Paul Smith <paul@mad-scientist.net>
- Date
- Nov 25, 2017, 18:26 UTC
- Message-ID
- <1511634365.2847.211.camel@mad-scientist.net>
- In-Reply-To
- <20171125175010.GB14993@hank>
On Sat, 2017-11-25 at 17:50 +0000, Thomas Gummerer wrote:
Show 20 quoted lines
> 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.