Re: .gitlink for Summer of Code

On Mon, Mar 26, 2007 at 09:33:44PM +0200, Josef Weidendorfer wrote:

The idea was to make this a possible building block for submodules.
A simple symlink does not work there when you want the checkout to
work even after moving the whole checkout directory around (e.g. to move the
submodule around inside of the superproject).

Well the submodule use case is a bit different than the lightweight
checkout.
When you store the submodule object database inside the supermodule then
you only need to store the position of the submodule relative to its
supermodule.  As you wrote this is neccessary in order to find the part
of the object database which belongs to this one submodule.
Finding the supermodule repository is obviously not difficult, only
finding the right part of it.
But for lightweight checkouts you need something which is closer to a
symlink.

quoted

So having an almost empty .git directory 
and reusing parts from another .git directory makes a lot of sense to
me.

This would work. However, you can not clone from an almost empty .git
directory with current git.

You can't clone from a .gitlink with current git, eighter ;-).
But if you e.g. set git_dir according to your link then everything
should work quite easily.

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.

What would you store in these per-checkout directories?
The index and HEAD?  Anything more?
For submodules I currently use <parent>/.git/objects/module/<submodule>/
to store the objects belonging to the submodule.
Perhaps it makes sense to extend this to a full .git directory per
submodule, I'm not yet decided on that.
For submodules the object store has to be different, but for normal
lightweight checkout this should of course be shared.

-- 
Martin Waitz