From: Jens Lehmann Date: Wed, 16 Feb 2011 20:10:27 GMT Subject: Re: [PATCH] submodule: no [--merge|--rebase] when newly cloned 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: > "Spencer E. Olson" 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..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.