Re: [PATCH] submodule: no [--merge|--rebase] when newly cloned

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 16.02.2011 20:51, schrieb Junio C Hamano:
> "Spencer E. Olson" <olsonse@umich.edu> writes:
> 
>> Previously, when a submodule was cloned in the same command execution, --rebase
>> or --merge would attempt to run (instead of and) before a checkout, resulting in
>> an empty working directory.  This patch ignores --rebase or --merge for a
>> particular submodule when that submodule is newly cloned and instead simply
>> checks out the appropriate revision.
> 
> Sorry, but I cannot parse the problem description, "(instead of and)" part.

I think what he wanted to say was that after a new submodule is cloned
by running "git submodule update" it will attempt to do a rebase or
merge without having checked out the submodule at all, which obviously
can't work. A plain checkout looks like the right thing to do, as there
aren't any local commits to rebase or merge yet.

> Why is it a better thing to do to ignore these options, instead of
> detecting the situation and error it out, saying "you are initially
> cloning, don't say --rebase"?

It should be fine to use these options when new submodules appear.
(And even without explicitly specifing these command line options
this bug can also be triggered by having the "submodule.<name>.update"
option set in .gitmodules to either "rebase" or "merge", which is easy
to miss)

So this looks like a worthwhile fix. The commit message and POSIX issue
need to be addressed, tests would be a good thing to add too, but apart
from that it looks sane.