Re: Minor missing features in worktree compare to new-workdir
>> 2. worktree doesn't seem to support multiple worktree on the same >> branch. > > 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 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. > 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!) 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).
Re: Minor missing features in worktree compare to new-workdir
On Wed, 2017-06-14 at 08:31 -0400, Yichao Yu wrote: > 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. 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. > 2. worktree doesn't seem to support multiple worktree on the same > branch. 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!)
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
