From: Johannes Sixt <hidden> Date: 2016-06-15 22:43:15
Lars Hjemli wrote:
(readded the gitlist)
On 6/12/07, Johannes Sixt [off-list ref] wrote:
quoted
Lars Hjemli wrote:
quoted
Multiple checkout paths for a single submodule will bring havoc on
this plan, so I need to ask: what is the use-case for multiple
checkout paths?
A use-case is the admin directory in the KDE repository. It has:
KDE (superproject)
+- kdelibs (subproject)
| +- admin (subproject)
| +- subdir1
| +- ...
+- kdebase (subproject)
| +- admin (subproject)
| +- subdir2
| +- ...
+- kdenetwork (subproject)
| +- admin (subproject)
| +- subdir3
| +- ...
...
But in this case, 'admin' isn't a submodule/subproject contained by
KDE, right? It's contained in three different submodules/subprojects:
kdelibs, kdebase and kdenetwork.
Notice how kdelibs, kdebase and kdenetwork are both submodule and
supermodule: They host the submodule admin and are hosted by KDE.
(If I missed the point, then it's because I didn't follow the
discussion; I jumped in because I noticed the symlink proposal by
chance.)
-- Hannes
From: Lars Hjemli <hidden> Date: 2016-06-15 22:43:15
On 6/12/07, Johannes Sixt [off-list ref] wrote:
Lars Hjemli wrote:
quoted
(readded the gitlist)
On 6/12/07, Johannes Sixt [off-list ref] wrote:
quoted
Lars Hjemli wrote:
quoted
Multiple checkout paths for a single submodule will bring havoc on
this plan, so I need to ask: what is the use-case for multiple
checkout paths?
A use-case is the admin directory in the KDE repository. It has:
KDE (superproject)
+- kdelibs (subproject)
| +- admin (subproject)
| +- subdir1
| +- ...
+- kdebase (subproject)
| +- admin (subproject)
| +- subdir2
| +- ...
+- kdenetwork (subproject)
| +- admin (subproject)
| +- subdir3
| +- ...
...
But in this case, 'admin' isn't a submodule/subproject contained by
KDE, right? It's contained in three different submodules/subprojects:
kdelibs, kdebase and kdenetwork.
Notice how kdelibs, kdebase and kdenetwork are both submodule and
supermodule: They host the submodule admin and are hosted by KDE.
Exactly my point ;-)
(If I missed the point, then it's because I didn't follow the
discussion; I jumped in because I noticed the symlink proposal by
chance.)
In this case, I would assume that e.g. kdelibs contain a submodule
entry for path admin in its index, accompanied by a .gitmodules file
saying that the path admin is mapped to this or that submodule. I
would not expect the KDE 'supersuperproject' to know about admin at
all, neither in its index nor .gitmodules.
--
larsh
In this case, I would assume that e.g. kdelibs contain a submodule
entry for path admin in its index, accompanied by a .gitmodules file
saying that the path admin is mapped to this or that submodule.
Exactly. That's just the "submodule" in "submodule" case we should
support, too.
I
would not expect the KDE 'supersuperproject' to know about admin at
all, neither in its index nor .gitmodules.
The admin submodule contains KDE specific things. So of course it
also would be a submodule in the grand whole KDE superduper module.
But that does not really matter.
However, to not have a lot of copies of the admin submodule
in
.git/submodule/admin
.git/submodule/kdelibs/.git/submodule/admin
.git/submodule/kdebase/.git/submodule/admin
.git/submodule/kdenetwork/.git/submodule/admin
the just suggested submodule.<name>.repopath to specify a repository
outside of .git/submodule to be shared by kdelibs,kdebase,... would
be fine.
Josef
From: Lars Hjemli <hidden> Date: 2016-06-15 22:43:15
On 6/12/07, Josef Weidendorfer [off-list ref] wrote:
On Tuesday 12 June 2007, Lars Hjemli wrote:
quoted
I
would not expect the KDE 'supersuperproject' to know about admin at
all, neither in its index nor .gitmodules.
The admin submodule contains KDE specific things. So of course it
also would be a submodule in the grand whole KDE superduper module.
Aha! But as you say:
But that does not really matter.
Exactly.
However, to not have a lot of copies of the admin submodule
in
.git/submodule/admin
.git/submodule/kdelibs/.git/submodule/admin
.git/submodule/kdebase/.git/submodule/admin
.git/submodule/kdenetwork/.git/submodule/admin
the just suggested submodule.<name>.repopath to specify a repository
outside of .git/submodule to be shared by kdelibs,kdebase,... would
be fine.
Yes, repopath would work out nice for KDE (which btw seems to be a
great test-case for git-submodule)
--
larsh
From: Johannes Sixt <hidden> Date: 2016-06-15 22:43:15
Josef Weidendorfer wrote:
However, to not have a lot of copies of the admin submodule
in
.git/submodule/admin
.git/submodule/kdelibs/.git/submodule/admin
.git/submodule/kdebase/.git/submodule/admin
.git/submodule/kdenetwork/.git/submodule/admin
the just suggested submodule.<name>.repopath to specify a repository
outside of .git/submodule to be shared by kdelibs,kdebase,... would
be fine.
This clearly shows that having the repositories of submodules in
.git/submodule does not buy you enough to avoid duplication.
(I don't see enough reason to place a repo for submodule X in project Y
outside its "natural" checked-out directory in project Y. But then, I
haven't followed the discussion. Please ignore me if above layout choice
is for more than just avoiding duplication.)
-- Hannes
From: Josef Weidendorfer <hidden> Date: 2016-06-15 22:43:15
On Tuesday 12 June 2007, Johannes Sixt wrote:
Josef Weidendorfer wrote:
quoted
However, to not have a lot of copies of the admin submodule
in
.git/submodule/admin
.git/submodule/kdelibs/.git/submodule/admin
.git/submodule/kdebase/.git/submodule/admin
.git/submodule/kdenetwork/.git/submodule/admin
the just suggested submodule.<name>.repopath to specify a repository
outside of .git/submodule to be shared by kdelibs,kdebase,... would
be fine.
This clearly shows that having the repositories of submodules in
.git/submodule does not buy you enough to avoid duplication.
The .git/submodule space for sure is not flexible enough for all
possible use cases of submodules (as with KDE repo).
However, as default it seems fine to me.
IMHO sharing of the admin submodule repository should even be possible
if I have a clone of kdelibs and kdebase independent of the big
KDE superproject.
It would be nice to allow submodule.<name>.repopath configs globally
in ~/.gitconfig, and cloning kdelibs should automatically do the
right thing, ie. use the already available admin repo for the kdelibs
clone.
(I don't see enough reason to place a repo for submodule X in project Y
outside its "natural" checked-out directory in project Y. But then, I
haven't followed the discussion.
To easily share the objects, branches and local modifications?
Currently a clone of a superproject always does a full copy of
any submodule databases because it is independent from any other
local git repository; in the KDE case you would get >4 admin copiess
if recursive cloning of submodules inside of submodules does that.
Josef
From: Josef Weidendorfer <hidden> Date: 2016-06-15 22:43:15
On Tuesday 12 June 2007, Josef Weidendorfer wrote:
IMHO sharing of the admin submodule repository should even be possible
if I have a clone of kdelibs and kdebase independent of the big
KDE superproject.
It would be nice to allow submodule.<name>.repopath configs globally
in ~/.gitconfig, and cloning kdelibs should automatically do the
right thing, ie. use the already available admin repo for the kdelibs
clone.
I just realize that this should be already possible now by setting
submodule.<name>.url in ~/.gitconfig. It could automatically
use "git-clone -l -s -n ..." if the URL is local.
Josef