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:

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;

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 [off-list ref] 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).

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:

On 10/1/06, Johannes Schindelin [off-list ref] wrote:

quoted

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).

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

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 [off-list ref] 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?

Matt

Hi,

On Sun, 1 Oct 2006, Matt McCutchen wrote:

On 10/1/06, Johannes Schindelin [off-list ref] wrote:

quoted

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?

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:

On 10/1/06, Johannes Schindelin [off-list ref] wrote:

quoted

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*