Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> writes: > This would work. However, you can not clone from an almost empty .git > directory with current git. Of course not. If you say "have .git/ <=> is a repository", then your lightweight checkout should not have a .git/. But why should anything that have a .git/ directory be a repository?? > The original proposal was to have a standard .git directory for every > light-weight checkout inside of the base .git directory, e.g. > in <base>/.git/ext/<name>.git where <name> is some identifier for the > lightweight checkout, either provided in the .gitlink file or > automatically determined. That seems really weird. That implies for example: * Deleting a checkout means deleting both your local tree _and_ a part of the .git/ directory of the repository. Have you ever imagined having to do more than "rm -fr working-tree" even with an inferior VCS such as CVS? * It makes it impossible to have a checkout of a read-only location. For example, if one of my colleague has a repository in /home/otheruser/repo/, if I want to get a working tree of it, I need to get a complete clone of his repo to be able to do it. Assuming someone ever implements a "lightweight checkout of a remote location" (bzr has this for example. You can run "bzr checkout --lightweigth http://whatever.com/), this would mean creating a directory on the server for each of the potential clients, not to mention the impossibility to do it over http. * You have to manage a name for each lightweight checkout. What would be such name? User-provided? uuidgen-like? I find the way bzr deals with this pretty elegant: a repository with a working tree is just a working tree and a repository located in the same directory. The repository stores its files (content of each revisions in history, ...) in .bzr/repository/, and the working tree stores them (the index, pending merges, ... and pointer to the corresponding branch) in .bzr/checkout/. -- Matthieu - 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