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

From: Jens Lehmann <jens.lehmann@web.de>
Date: Feb 16, 2011, 20:10 UTC
Message-ID: <4D5C2F33.8020309@web.de>
In-Reply-To: <7v62sjkbbi.fsf@alter.siamese.dyndns.org>

Am 16.02.2011 20:51, schrieb Junio C Hamano:

Show 9 quoted lines

> "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.