There is no .git dir for these. The .gitlink refers back to the main
repository's .git/external/$submodule, which is a full .git dir with
index+HEAD and symlinks back to the .git of the main repo for everything
else.
I don't see any contradiction.
Light checkouts would have an almost empty .git (it still needs an
index, and its own head anyway) and use the .git of the main repo for
everything else.
--
Matthieu
From: Eric Lesh <hidden> Date: 2016-06-15 22:43:01
On Mon, 2007-03-26 at 19:22 +0200, Matthieu Moy wrote:
I don't see any contradiction.
Light checkouts would have an almost empty .git (it still needs an
index, and its own head anyway) and use the .git of the main repo for
everything else.
Josef Weidendorfer tried to implement this before, and he concluded that
having a _text file_ .git, instead of a directory, would be a good way
to distinguish .gitlinked checkouts from normal checkouts.
As far as .git/link, that would seem to work better. As long as there
is a sanity check to make sure that you don't manage to mix things up,
it might be fine.
-Eric
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:01
hoi :)
On Mon, Mar 26, 2007 at 10:38:08AM -0700, Eric Lesh wrote:
quoted
Light checkouts would have an almost empty .git (it still needs an
index, and its own head anyway) and use the .git of the main repo for
everything else.
Josef Weidendorfer tried to implement this before, and he concluded that
having a _text file_ .git, instead of a directory, would be a good way
to distinguish .gitlinked checkouts from normal checkouts.
but that does not allow for per-checkout HEAD and index.
I don't see any reason for providing any sort for "gitlink" which
also uses HEAD and index from the linked location -- then you could
use a simple symlink, too. So having an almost empty .git directory
and reusing parts from another .git directory makes a lot of sense to
me.
--
Martin Waitz
From: Josef Weidendorfer <hidden> Date: 2016-06-15 22:43:01
On Monday 26 March 2007, Martin Waitz wrote:
hoi :)
On Mon, Mar 26, 2007 at 10:38:08AM -0700, Eric Lesh wrote:
quoted
quoted
Light checkouts would have an almost empty .git (it still needs an
index, and its own head anyway) and use the .git of the main repo for
everything else.
Josef Weidendorfer tried to implement this before, and he concluded that
having a _text file_ .git, instead of a directory, would be a good way
to distinguish .gitlinked checkouts from normal checkouts.
but that does not allow for per-checkout HEAD and index.
I don't see any reason for providing any sort for "gitlink" which
also uses HEAD and index from the linked location -- then you could
use a simple symlink, too.
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).
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.
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.
Hmm... the "almost empty .git directory" has its merits.
You can override config options, and of course, the "base" for the
lightweight checkout still can be a full .git dir, as would be needed
for submodule support. In fact, you have more freedom to choose the
path to the base gitdir.
I like it ;-)
So this changes the .gitlink proposal to:
* smartly reset GIT_DIR when a core.link option is set in .git/config
(and set GIT_WORK_DIR accordingly)
* fake a core.name if not set (this comes from the original proposal
to get an automatic identifier of a submodule checkout by its
relative path to the supermodule)
* git-checkout to allow to create a fresh light-weight checkout
Josef
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:01
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
From: Josef Weidendorfer <hidden> Date: 2016-06-15 22:43:01
On Tuesday 27 March 2007, Martin Waitz wrote:
On Mon, Mar 26, 2007 at 09:33:44PM +0200, Josef Weidendorfer wrote:
quoted
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.
Where do you store this in your module3 branch?
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.
Yes, of course.
quoted
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.
Yes.
quoted
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?
To make it easy to implement, I thought about a standard .git layout,
with most directories being symlinks.
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.
IMHO this would be a nice property. As the submodule could exist independently
with its own remote heads/tags, you probably would want to at least track these,
even if it is a submodule in your superproject.
And then it makes sense to move it directly to .git/module/...
There also was a use case where one library project is used in >10
superprojects. It would be nice to be able to make the submodule git dir
be outside of the supermodules git dir. However, this also can be done
with symlinks without any special support (aside from sharing the
head namespace).
Josef
For submodules the object store has to be different, but for normal
lightweight checkout this should of course be shared.
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:01
hoi :)
On Tue, Mar 27, 2007 at 01:00:12AM +0200, Josef Weidendorfer wrote:
On Tuesday 27 March 2007, Martin Waitz wrote:
quoted
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.
IMHO this would be a nice property. As the submodule could exist
independently with its own remote heads/tags, you probably would want
to at least track these, even if it is a submodule in your
superproject. And then it makes sense to move it directly to
.git/module/...
I am not sure that all the other submodule heads and tags really belong
into the superproject. Perhaps they should simply be handled in some
other way -- after all the submodule is a normal git repository and can
handle heads and tags on its own quite well.
But I haven't thought tag-handling for submodules through yet.
There also was a use case where one library project is used in >10
superprojects. It would be nice to be able to make the submodule git dir
be outside of the supermodules git dir. However, this also can be done
with symlinks without any special support (aside from sharing the
head namespace).
Of course you can always have a normal library.git repository with all
the tags and stuff somewhere and just fetch from there if you need
some central location for it. You could even add alternate entries
pointing there to the libraries object store inside the supermodule.
--
Martin Waitz