Re: [PATCH] git-merge: mutually match SYNOPSIS and "usage".

Junio C Hamano [off-list ref] writes:

Sergey Organov [off-list ref] writes:

quoted

Junio C Hamano [off-list ref] 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.