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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Sergey Organov <sorganov@xxxxxxxxx> writes:
>
>> Junio C Hamano <gitster@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]