From: Sergey Organov <sorganov@gmail.com>
Date: Wed, 08 Oct 2014 10:12:00 GMT
Subject: Re: [PATCH] git-merge: mutually match SYNOPSIS and "usage".
Message-ID: <87h9zeg9an.fsf@osv.gnss.ru>
In-Reply-To: <xmqq1tqjefd8.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>> Junio C Hamano <gitster@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.