From: Junio C Hamano Date: Tue, 07 Oct 2014 21:31:31 GMT Subject: Re: [PATCH] git-merge: mutually match SYNOPSIS and "usage". Message-ID: In-Reply-To: <87bnpnsjrw.fsf@osv.gnss.ru> Sergey Organov writes: > Junio C Hamano 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 " we will never fall into the traditional syntax, hence "git merge -m HEAD " appear to be allowed with "git merge [options] HEAD ...", but it is not. And the inverse is not true (an obvious example is "git merge $branch", even though it does not have "-m " it uses the modern & common. So the updated SYNOPSIS is not really helping. >> In other words, I agree with your motivation to call for attention >> that the command behaves differently with and without "-m", but I do >> not think that part of the change in this patch achieves it well. > > Any particular suggestion? I was going to suggest "explain how the traditional syntax is triggered in the DESCRIPTION section", but it turns out that we already do that. The second syntax ( HEAD ...) is supported for historical reasons. Do not use it from the command line or in new scripts. It is the same as git merge -m .... Strictly speaking, I think it is not qute "the same"---I recall vaguely that it broke tests if you replace the traditional-style invocation in 'git pull' with the -m syntax, but I do not have details handy; you may want to try it out if you are interested. So I would think SYNOPSIS git merge [options] ... git merge [options] HEAD ... git merge --abort should be sufficient, possibly with some clarification on "The second syntax" paragraph in the DESCRIPTION section.