undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

git-merge: document but discourage the historical syntax

Browse Source 
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>
This commit is contained in:
Junio C Hamano 2007-10-30 11:54:11 -07:00
parent b6c9fb5100
commit dee48c3c7e
1 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Documentation/git-merge.txt
View File

@ -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>