Stefan Beller [off-list ref] writes:
So you propose to make git-add behave like "git submodule add"
(i.e. also add the .gitmodules entry for name/path/URL), which I
like from a submodule perspective.
However other users of gitlinks might be confused[1], which is why
I refrained from "making every gitlink into a submodule". Specifically
the more powerful a submodule operation is (the more fluff adds),
the harder it should be for people to mis-use it.
A few questions that come to mind are:
- Does "git add sub/" have enough information to populate
.gitmodules? If we have reasonable "default" values for
.gitmodules entries (e.g. missing URL means we won't fetch when
asked to go recursively fetch), perhaps we can leave everything
other than "submodule.$name.path" undefined.
- Can't we help those who have gitlinks without .gitmodules entries
exactly the same way as above, i.e. when we see a gitlink and try
to treat it as a submodule, we'd first try to look it up from
.gitmodules (by going from path to name and then to
submodule.$name.$var); the above "'git add sub/' would add an
entry for .gitmodules" wish is based on the assumption that there
are reasonable "default" values for each of these $var--so by
basing on the same assumption, we can "pretend" as if these
submodule.$name.$var were in .gitmodules file when we see
gitlinks without .gitmodules entries. IOW, if "git add sub/" can
add .gitmodules to help people without having to type "git
submodule add sub/", then we can give exactly the same degree of
help without even modifying .gitmodules when "git add sub/" is
run.
- Even if we could solve it with "git add sub/" that adds to
.gitmodules, is it a good solution, when we can solve the same
thing without having to do so?
On Tue, Oct 10, 2017 at 4:31 PM, Junio C Hamano [off-list ref] wrote:
Stefan Beller [off-list ref] writes:
quoted
So you propose to make git-add behave like "git submodule add"
(i.e. also add the .gitmodules entry for name/path/URL), which I
like from a submodule perspective.
However other users of gitlinks might be confused[1], which is why
I refrained from "making every gitlink into a submodule". Specifically
the more powerful a submodule operation is (the more fluff adds),
the harder it should be for people to mis-use it.
A few questions that come to mind are:
- Does "git add sub/" have enough information to populate
.gitmodules? If we have reasonable "default" values for
.gitmodules entries (e.g. missing URL means we won't fetch when
asked to go recursively fetch), perhaps we can leave everything
other than "submodule.$name.path" undefined.
I think we would want to populate path and URL only.
- Can't we help those who have gitlinks without .gitmodules entries
exactly the same way as above, i.e. when we see a gitlink and try
to treat it as a submodule, we'd first try to look it up from
.gitmodules (by going from path to name and then to
submodule.$name.$var); the above "'git add sub/' would add an
entry for .gitmodules" wish is based on the assumption that there
are reasonable "default" values for each of these $var--so by
basing on the same assumption, we can "pretend" as if these
submodule.$name.$var were in .gitmodules file when we see
gitlinks without .gitmodules entries. IOW, if "git add sub/" can
add .gitmodules to help people without having to type "git
submodule add sub/", then we can give exactly the same degree of
help without even modifying .gitmodules when "git add sub/" is
run.
I do not understand the gist of this paragraph, other then:
"When git-add <repository> encounters a section submodule.<name>.*,
do not modify it; We can assume it is sane already."
- Even if we could solve it with "git add sub/" that adds to
.gitmodules, is it a good solution, when we can solve the same
thing without having to do so?
I am confused even more.
So you suggest that "git add [--gitlink=submodule]" taking on the
responsibilities of "git submodule add" is a bad idea?
I thought we had the same transition from "git remote update" to
"git fetch", which eventually superseded the former.
On Wed, Oct 11, 2017 at 08:31:37AM +0900, Junio C Hamano wrote:
Stefan Beller [off-list ref] writes:
quoted
So you propose to make git-add behave like "git submodule add"
(i.e. also add the .gitmodules entry for name/path/URL), which I
like from a submodule perspective.
However other users of gitlinks might be confused[1], which is why
I refrained from "making every gitlink into a submodule". Specifically
the more powerful a submodule operation is (the more fluff adds),
the harder it should be for people to mis-use it.
A few questions that come to mind are:
- Does "git add sub/" have enough information to populate
.gitmodules? If we have reasonable "default" values for
.gitmodules entries (e.g. missing URL means we won't fetch when
asked to go recursively fetch), perhaps we can leave everything
other than "submodule.$name.path" undefined.
My suggestion would be: If we do not have them we do not populate them.
We could even go further and say: If we do not have the set "git
submodule add" would populate then we do not add anything to .gitmodules
and warn the user.
- Can't we help those who have gitlinks without .gitmodules entries
exactly the same way as above, i.e. when we see a gitlink and try
to treat it as a submodule, we'd first try to look it up from
.gitmodules (by going from path to name and then to
submodule.$name.$var); the above "'git add sub/' would add an
entry for .gitmodules" wish is based on the assumption that there
are reasonable "default" values for each of these $var--so by
basing on the same assumption, we can "pretend" as if these
submodule.$name.$var were in .gitmodules file when we see
gitlinks without .gitmodules entries. IOW, if "git add sub/" can
add .gitmodules to help people without having to type "git
submodule add sub/", then we can give exactly the same degree of
help without even modifying .gitmodules when "git add sub/" is
run.
This "default" value thing got me thinking in a different direction. We
could use a scheme like that to get names (and values) for submodules
that are missing from the .gitmodules file. If we decide that we need to
handle them.
Cheers Heiko