Re: [PATCH v3 1/6] worktree: new repo extension to manage worktree behaviors
- From
Dennis Kaarsemaker <dennis@kaarsemaker.net>
- Date
- Feb 1, 2016, 18:39 UTC
- Message-ID
- <1454351978.13104.6.camel@kaarsemaker.net>
- In-Reply-To
- <xmqqfuxi7jtn.fsf@gitster.mtv.corp.google.com>
On wo, 2016-01-27 at 14:12 -0800, Junio C Hamano wrote:
Show 11 quoted lines
> More seriously, are we confident that the overall worktree support > is mature enough by now that once we add an experimental feature X > at version 1, we can promise to keep maintaining it forever at > version N for any positive integer N? I hate to sound overly > negative, but I am getting an impression that we are not quite > there, and it is still not ready for production use. > > It would be beneficial both for us and our users if we can keep our > hand untied for at least several more releases to allow us try > various random experimental features, fully intending to drop any of > them if the ideas do not pan out.
So far I have two use cases for separate worktrees and am a happy user:
- A CI setup that tries to avoid cloning a repository too often. It does N independent tasks in parallel in separate worktrees. This checks out the same commit multiple times in multiple worktrees.
- Quickly checking out another branch/commit without first having to stash all uncommitted work.
Neither of those require much specialness, so I'm more than happy to see things change for the better as we find out more of the edge cases. One thing that may benefit especially the former is a 'git worktree rm' which removes the worktree (iff there are no local changes) and prunes it, but nothing in the current implementation or proposed changes will stop the addition of that.
-- Dennis Kaarsemaker www.kaarsemaker.net