On Thu, Sep 15, 2016 at 11:02 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> I think that is a more pressing thing to address. Once we make it
> easier for the user to bring a half-initialized submodule properly
> into the world view of the submodule subsystem, we would have to
> worry about the reported failure case even less and you do not need
> to pile on workaround options to let things continue in a state that
> is half-broken (that is, in a state that is perfectly sane to the
> core layer, but is not liked by the submodule layer).
Heh, I see.
When searching around the net, some people use half
initialized submodules intentionally, e.g. I'll store some private keys in
sub and I publish the superproject asking for collaborators to my new shiny
webbased thing. The submodule containing the private keys never leaves
my hard drive, hence no .gitmodules entry is necessary.
Not sure I agree with such a setup, but people use it.
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.
$ git submodule
... similar advice goes here...
fatal: no submodule mapping found in .gitmodules for path 'sub'
$ git submodule add --fixup-modules-file ./sub sub
Adding .gitmodule entry only for `sub` to use `git -C remote
show origin` as URL.
# user is happy now.