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

[Marius Storm-Olsen <marius@trolltech.com>]

[-- Attachment #1: Type: text/plain, Size: 3056 bytes --]

Junio C Hamano wrote:
> 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.
...
> 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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]