On Tue, Dec 10, 2013 at 3:46 PM, Dominik Vogt <v...@linux.vnet.ibm.com> wrote:
> > I suspect the simplest way to accomplish what you're looking for would
> > be to keep separate worktrees for each branch you regularly build.
> > It's possible to do that using entirely independent clones, clones
> > sharing some objects (using "git clone --shared" from some master
> > copy), or even multiple worktrees for the same clone (using the
> > git-new-workdir script from contrib/workdir/).
> I've tried the first two ways for separate workdirs in the past
> but did not like them.  How does git-new-workdir cope with
> rebasing (e.g. you have the same branch checked out in two working
> trees and "rebase -i" it in one of them)?  Is it really a working
> option?

I wonder if we could promote multiple worktree from a hack to a
supported feature. What I have in mind is when you "clone
--separate-worktree" it would create a .git file that describes
separate worktree:

gitbasedir: /path/to/the/original/.git
name: foo

HEAD, index and logs/HEAD would be stored in
/path/to/the/original/.git/worktrees/foo/. GIT_DIR would be set to
covers root for all refs/, logs/ and packed-refs) and maybe
GIT_HOOKS_DIRECTORY are pointed to directories in
.../original/.git/... though.

This allows all worktrees to be aware of the others and locking could
be implemented so that no two worktrees check out the same branch (or
they can, but the other becomes detached if the ref is updated in this
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to