Junio C Hamano <gits...@pobox.com> writes: > Sergey Organov <sorga...@gmail.com> writes: > >> Junio C Hamano <gits...@pobox.com> writes: >> ... >> I was looking at the merge.c code, and that's how it seems to work. You >> can get new semantics without -m, and you can't get old semantics with >> -m, isn't it? It looks like the set of descriptions I produced is >> formally correct. > > The thing is, with "-m <msg>" we will never fall into the > traditional syntax, hence "git merge -m <msg> <msg> HEAD <commit>" > appear to be allowed with "git merge [options] <msg> HEAD > <commit>...", but it is not.
No. When you see: git merge [options] [-m <msg>] <commit>... Isn't it obvious that 'options' don't include "-m <msg>", so git merge [options] <msg> HEAD <commit>... form will never apply when you have "-m <msg>" in the command, exaclty because 'options' don't include "-m <msg"? > > And the inverse is not true (an obvious example is "git merge > $branch", even though it does not have "-m <msg>" it uses the modern > & common. Sure, and this is covered as well. > So the updated SYNOPSIS is not really helping. I disagree, see above. I still think that for somewhat messy historical situation, the suggested syntax description is good enough. -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
