On Tue, Dec 10, 2013 at 3:46 PM, Dominik Vogt <vogt@xxxxxxxxxxxxxxxxxx> 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 .../foo/, GIT_OBJECT_DIRECTORY, the new GIT_REF_DIRECTORY (which 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 worktree).. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html