Multiple checkouts of the same repository

Multiple checkouts of the same repository

[Matt McCutchen]

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

Re: Multiple checkouts of the same repository

[Johannes Schindelin]

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

Re: Multiple checkouts of the same repository

[Matt McCutchen]

On 10/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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

Re: Multiple checkouts of the same repository

[Johannes Schindelin]

Hi,

On Sun, 1 Oct 2006, Matt McCutchen wrote:

> On 10/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

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

Re: Multiple checkouts of the same repository

[Matt McCutchen]

On 10/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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

Re: Multiple checkouts of the same repository

[Johannes Schindelin]

Hi,

On Sun, 1 Oct 2006, Matt McCutchen wrote:

> On 10/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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?

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

Re: Multiple checkouts of the same repository

[Daniel Barkalow]

On Sun, 1 Oct 2006, Matt McCutchen wrote:

> On 10/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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*

Re: Multiple checkouts of the same repository

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

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

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