On Sun, 1 Oct 2006, Matt McCutchen wrote: > On 10/1/06, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > The fact is, your setup is fragile, and I think that is hard to fix if you > > do not make A and B git repositories in their own right. > > I think my setup is much simpler than having two separate repositories > that update each other using hooks. What can go wrong, besides the > scenario I mentioned where one working tree doesn't get updated when I > commit through the other one? It works fine, so long as you never modify in A the head that's checked out in B; if you do this, git will be very confused, because it doesn't record in the index what commit the index comes from. I did this for a while, but eventually switched to just having a single branch checked out at a time. (The other thing is that you probably want to have the non-symlinked repository be bare, i.e., not checked out, and have multiple sets of symlinks to its parts, so if you decide to discard a working directory, you don't accidentally delete the one with the repository actually in it.) At one point, I was arguing for storing the information of what commits were the starting point of the current index in the index itself, instead of relying on external files and external links to refs, but I wasn't really working on git enough to argue for it effectively. Among other things, it would allow git to know what's going on if the head changes without the index getting updated. (Of course, all of the cases it supports are really ones where git should just tell you that you've done something wrong, because you can't really do non-linear work in a single head sensibly, because there's only one ref for the head, which can't jump sideways from the commit that's been pulled or generated elsewhere to the commit that's being generated from the index; if the head doesn't match the commit the index is from, there is no alternative to a merge-before-commit, which is frowned upon in the git world as a way of losing your recent work. This is why I couldn't convince people very well.) -Daniel *This .sig left intentionally blank* - 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