Re: '.git file' alternative, native (cross-platform) workdir support.

From: Marius Storm-Olsen <marius@trolltech.com>
Date: Feb 29, 2008, 21:32 UTC
Message-ID: <47C879EE.2000808@trolltech.com>
In-Reply-To: <7vabljcyzh.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

Show 5 quoted lines

> The primary reason we may want to do the ".git file" thing is to
> sanely support switching between branches (or checking out a
> different revision, which amounts to the same thing) when one has a
> submodule and the other one either does not have that submodule
> anywhere or have it in a different location in its tree.

...

Show 15 quoted lines

> One way to solve this would be to add .git/submodules/paulus.git 
> repository inside the controlling reopsitory of the toplevel project,
> and point that with the ".git file" installed at gitk-git/.git, when
> we are on HEAD.  We can lose gitk-git directory and everything below
> it when switching away from the revision, but when we come back, we
> can recreate gitk-git directory, point gitk-git/.git back to
> .git/submodules/paulus.git kept in the toplevel repository, and check
> the appropriate commit out there.
> 
> After switching to an old revision that did not have the submodule, 
> further switching to a branch that has the submodule at modules/gitk
> would be the same deal.  Instead of creating gitk-git directory and
> installing the ".git file" there (which is what we did when we came
> back to the original HEAD), create modules/gitk and install the ".git
> file" there, to point at the same .git/submodules/paulus.git/.

Ahh, ok, this makes sense. *Then* you need to point all of .git to a specific location. But, in this case you're not interested in keeping n-different states, as we are in a multiple workdir situation. So, it's a much easier case.

The question is, is this also the appropriate basis for solving the multiple workdir case? If so, we need to come up with a scheme that lets us keep n number of states inside one single .git structure. Is this reasonable? It's not like it's too hard, just a bit messy.

The reason I ask is to evaluate if I should cleanup the patch I did for the native workdir support that started out this thread, or just lay it dead for the '.git file' solution which still would need a lot of work before it's finished. (Though, as I said before, my redirection way could certainly migrate into a '.git file' solution over time)

I basically just need a certain amount of knowledgeable people to either say 'drop it' or 'roll with it'.. I'm ambivalent, though I want workdirs on Windows yesterday. :-) So, I guess I have Dscho's -1, and my own +1 = 0 :-p

> We should be able to do this today without ".git file" using
> symlinks. It's just a Porcelain hackery, so I'll leave it to
> interested parties as an exercise.

Symlinks wouldn't really work, unless you force people to always keep their full .git next to the workdir. So, multiple workdirs with submodules would then fail, as would FS without symlink support (duh). This seems to be the issue with the current '.git file' implementation as well. If the repo is not located next to the workdir, it will fail. Or am I reading the code incorrectly? And what happens with recursive submodules?

-- .marius