Re: [RFC] separate .git from working directory

[Sergio Callegari <scallegari@arces.unibo.it>]

Possibly a bit different from the RFC, however,

Other than making find happy, I see other potential advantages in supporting 
the two options of having .git be either

- a directory containing all the git stuff
- a single file with a pointer to the real directory containing the objects, 
references, branches, etc.

1) It might make the life easier on platforms where symlinks are not the 
easiest thing to do (are there any?)

2) it might make it easier to work with syncronization tools (some of you 
might know that I got burnt with them recently). One of the issues of 
syncronizatoin tools is that they typically recognize renames as the 
non-atomical sequence of creation+deletion. Hence imagine the following 
scenario. I have ProjectFoo with the .git dir in. I tell the syncronization 
tool to ignore things called .git (not to get burned again!). I decide to 
rename ProjectFoo into ProjectBar. When I sync, I get with a ProjectBar with 
no .git directory since .git was meant to be ignored and is consequently lost 
in the creation+deletion sequence. All objects are then lost at one of the 
two hosts participating in the syncronization. If .git was only a file with a 
pointer, it would at least be possible to recreate it by hand without 
depending on the other syncronization host.

3) it might make it possible to have all the git archives in a single place, 
where it is easy to program a script to scan all the archives and repack all 
of them periodically or to scan all of them and backup them periodically, 
etc.

Sergio