Am 06.02.2011 21:45, schrieb Junio C Hamano: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > >> Yes, but isn't that exactly what the pull man-page says? Quote: >> "Options meant for git pull itself and the underlying git merge >> must be given before the options meant for git fetch." > > Yes, it says that, and I think that was a weasely way to say "the command > line parser in git-pull is broken". The lines you are removing was from > the patch that fixed that breakage, aren't they? Nope, they were from the patch where I taught "git fetch" the "--recurse-submodules" option and was not aware at that time that "git pull" should just pass on almost all fetch options (the only exceptions to that rule being -q, -v, -n and --progress). The thing I had in mind was to later pass the same "--recurse-submodules" option to the merge command too (when I finished implementing that option). But when I understood later that pull handles the fetch options in an interesting way I noticed that it would depend on the order of options given if the "--recurse-submodules" would then be passed to both fetch and merge or just to fetch, which will lead to an interesting and unintuitive behavior I was not eager to expose. So yes, I hit the strangeness of the "git pull" option parsing, but decided to not mess it up further by adding another option to the ones it does handle differently but play by the rules which are used now (The other possibility would have been to document it as a new option to "git pull", but that would have lead to the problem I described earlier when merge will learn that option too). So I have no strong feelings about this patch but believe it is the right thing to do as long as "git pull" handles its options the way it does. But looking at the confusion that option handling caused I think it might be a worthwhile idea to overhaul it. (CCed Jonathan, as he is the author of the lines I quoted) -- 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