git-merge: document but discourage the historical syntax

Historically "git merge" took its command line arguments in a rather strange order. Document the historical syntax, and also document clearly that it is not encouraged in new scripts. There is no reason to deprecate the historical syntax, as the current code can sanely tell which syntax the caller is using, and existing scripts by people do use the historical syntax. Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-mirror · Oct 30, 2007 · dee48c3 · dee48c3
1 parent b6c9fb5
commit dee48c3
Showing 1 changed file with 6 additions and 5 deletions.
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
@@ -11,26 +11,27 @@ SYNOPSIS
 [verse]
 'git-merge' [-n] [--summary] [--no-commit] [--squash] [-s <strategy>]...
 	[-m <msg>] <remote> <remote>...
+'git-merge' <msg> HEAD <remote>...
 
 DESCRIPTION
 -----------
 This is the top-level interface to the merge machinery
 which drives multiple merge strategy scripts.
 
+The second syntax (<msg> `HEAD` <remote>) 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 <msg> <remote>`.
+
 
 OPTIONS
 -------
 include::merge-options.txt[]
 
-<msg>::
+-m <msg>::
 	The commit message to be used for the merge commit (in case
 	it is created). The `git-fmt-merge-msg` script can be used
 	to give a good default for automated `git-merge` invocations.
 
-<head>::
-	Our branch head commit.  This has to be `HEAD`, so new
-	syntax does not require it
-
 <remote>::
 	Other branch head merged into our branch.  You need at
 	least one <remote>.  Specifying more than one <remote>