Minor missing features in worktree compare to new-workdir

Hi,

I've just learnt recently that the new-workdir script has finally got a builtin version, i.e. worktree. I've given it a short try and for the most part it works as good or better than new-workdir.

However, there's few minor features that I use in new-workdir that doesn't seem to be supported by worktree.

1. the branch name in new-workdir has the same behavior as checkout,
i.e. when it matches a remote branch name a local branch tracking that
remote branch will be created and checked out. worktree gives an error
in this case. This is very useful for fetching someone else' feature
branch into a different work dir for testing.

2. worktree doesn't seem to support multiple worktree on the same
branch. I do this for testing different options and also to checkout a
base branch on a worktree before deleting the dev branch checked out
in the workdir. This will indeed cause one of the checkout to be dirty
when the branch is updated somewhere else but it doesn't seem to cause
much issue otherwise. (this mainly happen when I forgot to remove a
workdir so the solution is usually just remove that out-of-date
checkout).

3. There's an error when the branch name is omitted but the default
brach name already exist. Can it default to checking out the branch if
it already exist instead? (The behavior of creating new branch is of
course also useful when the branch doesn't exist)

4. worktree doesn't seem to be runable outside a git repo. new-workdir
can. This is pretty minor and mainly useful when checking out a branch
that matches the nested structure in the branch name (i.e. I'd like to
checkout branch A/B/C into A/B/C/ while master branch is in master/. I
usually first cd to A/B before running git new-workdir ../../master C)
This only saves a little typing in certain cases so it's a very minor
issue.....

All tests are done 2.13.1 from ArchLinux official repo.

Thanks.

Yichao Yu

On Wed, 2017-06-14 at 08:31 -0400, Yichao Yu wrote:

I agree; this behavior of worktree is frustrating. It's a very common use-case to aid in code reviews etc. and it's not easy to explain to people what they need to do to make this work.

I think this is a very good thing about worktrees as opposed to workdirs.

In a situation where I may want multiple worktrees pointing to the same commit I just check out the SHA rather than the branch: you can have as many branches set to the same SHA (detached HEAD) as you like, and there's no concern about dirty workspaces. This latter can actually be a really big problem (suppose the workdir contained some modified files then you update another workdir with the same branch... it's not easy to figure out what happened here!)

Hmm, this could be workable. Though in that case it'll be nice to have a easier way to checkout the SHA corresponding to a branch.

Unless it can cause internal corruption I'd still prefer to allow this with warning/option. I have indeed cause dirty state myself though 95% of the time it's because I forgot to remove the checkout that I'm done using and the rest 5% being temperary state that I intentionally cause (e.g. update in one checkout before hard resetting the second one).