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

From: Jens Lehmann <[email-masked]>
Date: Wed, 16 Feb 2011 21:10:27 +0100

Am 16.02.2011 20:51, schrieb Junio C Hamano:
> "Spencer E. Olson" <[email-masked]> 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.