Multiple checkouts of the same repository

Dear git people,

Maybe this is common knowledge, but I thought I should mention it in case it isn't. I had a git repository in a directory A and I wanted to check out a branch of the repository to a different directory B. So I created B/.git and filled it with symlinks pointing to the files in A/.git, except for index and HEAD because those need to be different for each checkout; then I ran git-checkout <branch> to fill B. Now I can view and edit each checkout independently, but they are backed by the same set of objects and refs. However, I must remember to commit to each branch only through the checkout whose HEAD is linked to it, otherwise that checkout won't get updated.

Matt

Hi,

On Sun, 1 Oct 2006, Matt McCutchen wrote:

A better method is to use a local clone:

	git-clone --local --shared A  B

Such a clone will be very fast, and cheap, because it sets up links (not just symbolic links, but links that git understands).

Hth, Dscho

On 10/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

But that gives me two separate repositories, so I have to push and pull to keep them in sync, which is a pain.

I symlinked only the top-level things in .git, not the individual files inside them. That is to say, B/.git/objects is a symlink to A/.git/objects, B/.git/refs is a symlink to A/.git/refs, etc. In fact, this is necessary for A to see objects and refs written through B.

Matt

Hi,

On Sun, 1 Oct 2006, Matt McCutchen wrote:

So you want the commits to show in A, too? I propose using a hook for that.

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.

Hth, Dscho

On 10/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

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?

Matt

Hi,

On Sun, 1 Oct 2006, Matt McCutchen wrote:

I do not know, but it feels wrong. Git does not expect something like this, much like an operating system does not expect another computer to access its root hard disk. So _I_ think your setup is fragile.

Ciao, Dscho

On Sun, 1 Oct 2006, Matt McCutchen wrote:

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*

Daniel Barkalow <barkalow@iabervon.org> writes:

I think if you really wanted to, you could put it in the index extension section along with the cache-tree data. We would need to implement a way to query and manipulate data in the index extension and update git-commit (it should check HEAD matches the commit you placed in the extension earlier, and after making a commit and updating HEAD, you should update the index with the new commit as well), git-checkout (after switching branches you should update the index with the branch head you switched to; I think you should sanity check before switching to see if the current index and HEAD are reasonable as well but I am not sure), git-reset --hard (set to the resetted HEAD), git-am, git-applymbox, and git-merge (check before and set after when successful).