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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html