Stefan Beller [off-list ref] writes:
When searching around the net, some people use half
initialized submodules intentionally,...
Not sure I agree with such a setup, but people use it.
In such a top-level project, people would not use "git submodule"
command, would they? I do not think anybody in this thread was
pushing to forbid such a use, and it may be perfectly fine if "git
submodule" does not work for such a gitlink; after all such a
subdirectory is not even meant to be a submodule.
So how about this fictional work flow:
$ git init top
$ cd top
$ git commit --allow-empty -m 'initial in top'
$ git init sub
$ git -C sub commit --allow-empty -m 'initial in sub'
$ git add sub
You added a gitlink, but no corresponding entry in
.gitmodules is found. This is fine for gits core functionality, but
the submodule command gets confused by this unless you add 'sub'
to your .gitmodules via `git submodule add --already-in-tree \
--reuse-submodules-origin-as-URL sub`. Alternatively you can make this
message disappear by configuring advice.gitlinkPitfalls.
I am not sure if I agree with that direction.
If the trend in Git community collectively these days is to make
usage of submodules easier and smoother, I'd imagine that you would
want to teach "git add" that was given a submodule to "git submodule
add" instead by default, with an option "git add --no-gitmodules
sub" to disable it, or something like that.
$ git submodule add --fixup-modules-file ./sub sub
Adding .gitmodule entry only for `sub` to use `git -C remote
show origin` as URL.
I agree that a feature like this is needed regardless of what
happens at "git add" time.
On Thu, Sep 15, 2016 at 11:27:54AM -0700, Junio C Hamano wrote:
Stefan Beller [off-list ref] writes:
quoted
So how about this fictional work flow:
$ git init top
$ cd top
$ git commit --allow-empty -m 'initial in top'
$ git init sub
$ git -C sub commit --allow-empty -m 'initial in sub'
$ git add sub
You added a gitlink, but no corresponding entry in
.gitmodules is found. This is fine for gits core functionality, but
the submodule command gets confused by this unless you add 'sub'
to your .gitmodules via `git submodule add --already-in-tree \
--reuse-submodules-origin-as-URL sub`. Alternatively you can make this
message disappear by configuring advice.gitlinkPitfalls.
I am not sure if I agree with that direction.
If the trend in Git community collectively these days is to make
usage of submodules easier and smoother, I'd imagine that you would
want to teach "git add" that was given a submodule to "git submodule
add" instead by default, with an option "git add --no-gitmodules
sub" to disable it, or something like that.
quoted
$ git submodule add --fixup-modules-file ./sub sub
Adding .gitmodule entry only for `sub` to use `git -C remote
show origin` as URL.
I agree that a feature like this is needed regardless of what
happens at "git add" time.
How about just
git submodule add <submodulepath>
? I remember back in the days when I started with submodules thats the
way I imagined submodules would work:
1. clone the submodule into a directory
2. git submodule add it
3. git commit everything
Because that how you basically work with files. So instead of adding
another option I would rather like to autodetect that:
* its a relative path inside this repo that is passed to
'git submodule add'
* there is no .gitmodules entry
* and no .git/config
==> create those from a remote in the submodule
Corner cases:
* If there is more than one remote we could tell the user to use an
option to specify which one to use.
* Barf in case there is no remote (not adding the submodule except -f
is used).
* If the gitlink is already there but no .gitmodules entry, 'git
submodule add' will just add the entry as if it was initially added.
Instead of giving an error message that the submodule is already added
we could actually be nicer to the user and try to fix things for him
instead.
Cheers Heiko
On Fri, Sep 16, 2016 at 7:11 AM, Heiko Voigt [off-list ref] wrote:
How about just
git submodule add <submodulepath>
? I remember back in the days when I started with submodules thats the
way I imagined submodules would work:
1. clone the submodule into a directory
2. git submodule add it
3. git commit everything
Because that how you basically work with files. So instead of adding
another option I would rather like to autodetect that:
* its a relative path inside this repo that is passed to
'git submodule add'
* there is no .gitmodules entry
* and no .git/config
==> create those from a remote in the submodule
Corner cases:
* If there is more than one remote we could tell the user to use an
option to specify which one to use.
* Barf in case there is no remote (not adding the submodule except -f
is used).
* If the gitlink is already there but no .gitmodules entry, 'git
submodule add' will just add the entry as if it was initially added.
Instead of giving an error message that the submodule is already added
we could actually be nicer to the user and try to fix things for him
instead.
This makes sense to me. Possibly we could warn in this case, so that
the user knows that something was "off" but I don't think we should be
failing here...
Regards,
Jake
Cheers Heiko