Am 16.02.2011 20:51, schrieb Junio C Hamano: > "Spencer E. Olson" <olsonse@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html