Junio C Hamano <junkio <at> cox.net> writes: > > Michael Poole <mdpoole <at> troilus.org> writes: > > > This all sounds a lot like git-clone's "alternate" code. > > ... > > My own work habits are very similar to Bill Lear's, but my projects' > > build times are small enough that it's less pain to rebuild half the > > project than to propagate changes recorded under $GIT_DIR between > > local branches. I have not found a git workflow that makes me > > entirely happy, but I suspect I just don't know the magic words. > > These days I use a few working trees that are connected to my > primary repository (which also has a working tree). The primary > repository is in /src/git, and other ones look like this: > > : gitster git.wk0; ls -l .git/ > total 120 > drwxrwsr-x 3 junio src 4096 Mar 5 16:22 ./ > drwxrwsr-x 15 junio src 16384 Mar 5 16:23 ../ > -rw-rw-r-- 1 junio src 41 Mar 5 16:22 HEAD > lrwxrwxrwx 1 junio src 27 Mar 3 22:53 config -> /src/git/.git/config > lrwxrwxrwx 1 junio src 26 Mar 3 22:53 hooks -> /src/git/.git/hooks/ > -rw-rw-r-- 1 junio src 82455 Mar 5 16:22 index > lrwxrwxrwx 1 junio src 25 Mar 3 22:53 info -> /src/git/.git/info/ > drwxrwsr-x 3 junio src 4096 Mar 3 22:59 logs/ > lrwxrwxrwx 1 junio src 28 Mar 3 22:53 objects -> /src/git/.git/objects/ > lrwxrwxrwx 1 junio src 32 Mar 3 22:53 packed-refs -> /src/git/.git/packed-refs > lrwxrwxrwx 1 junio src 25 Mar 3 22:53 refs -> /src/git/.git/refs/ > lrwxrwxrwx 1 junio src 28 Mar 3 22:53 remotes -> /src/git/.git/remotes/ > lrwxrwxrwx 1 junio src 29 Mar 3 22:53 rr-cache -> /src/git/.git/rr-cache/ > > It shares everything other than HEAD and the index (the reflog > for branches are also shared by a symlink .git/logs/refs > pointing at the one in the primary repository). > > This risks confusion for an uninitiated if you update a ref that > is checked out in another working tree, but modulo that caveat > it works reasonably well. > > We might want to add an option to 'git-clone' to create > something like this, but I am somewhat worried about the newbie > confusion factor. Perhaps... > > $ git clone --i-know-what-i-am-doing-give-me-an-alternate-working-tree \ > /src/git /src/git.wk0 > > This looks very much like the .gitlink approach that was previously proposed on the list, I think... In that proposal, rather than having many symlinks in the .git repo, you would have a single .gitlink one... (plus, obviously a live index and HEAD). Possibly, the .gitlink approach could be better, since in case the *real* repo needs for some reason to be moved, then you just need to update a single link rather than many of them (this might also be safer... just imagine a scenario where one updates the links by hand and forgets to update one of them... and more friendly to OSes disliking symbolic links). You mention the fact that the only possible confusion here is if a ref that is checked out in another working tree gets updated... Something like I update master on WT A, but another WT B has master checked out, so the status of the WT in B gets old with regard to the new branch tip... I guess that in this case committing in WT B could be a disaster... However, if in HEAD we stored not just the branch-ref, but also its commit ID this case could become very easy to spot... and we could start behaving as if we were headless... (possibly safer)... or am I completely wrong? Sergio - 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