Re: .gitlink for Summer of Code

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Mar 26, 2007, 19:49 UTC
Message-ID: <vpqodmfss39.fsf@olympe.imag.fr>
In-Reply-To: <200703262133.44520.Josef.Weidendorfer@gmx.de>

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> 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??

Show 5 quoted lines

> 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