# [PATCH] core-tutorial: git-merge uses -m for commit messages 4 messages from 2007-02-05 to 2007-02-06. Participants: Matthias Lederhofer, Junio C Hamano. Thread: https://gitlist.dev/t/6690 ## Matthias Lederhofer, 2007-02-05 11:34 Subject: [PATCH] core-tutorial: git-merge uses -m for commit messages Message-ID: <20070205113439.GA27077@moooo.ath.cx> URL: https://gitlist.dev/e/20070205113439.GA27077%40moooo.ath.cx ``` Signed-off-by: Matthias Lederhofer --- Documentation/core-tutorial.txt | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt index 9c28bea..6f30e0a 100644 --- a/Documentation/core-tutorial.txt +++ b/Documentation/core-tutorial.txt @@ -894,11 +894,11 @@ script called `git merge`, which wants to know which branches you want to resolve and what the merge is all about: ------------ -$ git merge "Merge work in mybranch" HEAD mybranch +$ git merge -m "Merge work in mybranch" HEAD mybranch ------------ -where the first argument is going to be used as the commit message if -the merge can be resolved automatically. +The `-m` options specifies the commit message to be used for the merge commit +(in case it is created). Now, in this case we've intentionally created a situation where the merge will need to be fixed up by hand, though, so git will do as much @@ -981,7 +981,7 @@ resolve to get the "upstream changes" back to your branch. ------------ $ git checkout mybranch -$ git merge "Merge upstream changes." HEAD master +$ git merge -m "Merge upstream changes." HEAD master ------------ This outputs something like this (the actual commit object names @@ -1623,8 +1623,8 @@ in both of them. You could merge in 'diff-fix' first and then 'commit-fix' next, like this: ------------ -$ git merge 'Merge fix in diff-fix' master diff-fix -$ git merge 'Merge fix in commit-fix' master commit-fix +$ git merge -m 'Merge fix in diff-fix' master diff-fix +$ git merge -m 'Merge fix in commit-fix' master commit-fix ------------ Which would result in: -- 1.5.0.rc3.544.g79b8 ``` ## Junio C Hamano, 2007-02-05 18:07 Subject: Re: [PATCH] core-tutorial: git-merge uses -m for commit messages Message-ID: <7vejp4mqad.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vejp4mqad.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20070205113439.GA27077@moooo.ath.cx> ``` Matthias Lederhofer writes: > Signed-off-by: Matthias Lederhofer > --- > Documentation/core-tutorial.txt | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt > index 9c28bea..6f30e0a 100644 > --- a/Documentation/core-tutorial.txt > +++ b/Documentation/core-tutorial.txt > @@ -894,11 +894,11 @@ script called `git merge`, which wants to know which branches you want > to resolve and what the merge is all about: > > ------------ > -$ git merge "Merge work in mybranch" HEAD mybranch > +$ git merge -m "Merge work in mybranch" HEAD mybranch > ------------ Unfortunately it needs more than that. The funny command argument order in the original example was the command line format that has been in use internally for a long time: merge HEAD . The human-accessible form that uses -m in front of does not need the second argument that always must match the current commit (it always must match so there is no point saying it). The original examples work perfectly Ok, and you broke it -- if you are doing '-m' you need to remove HEAD (and master in later ones) from the command line. ``` ## Matthias Lederhofer, 2007-02-05 18:32 Subject: Re: [PATCH] core-tutorial: git-merge uses -m for commit messages Message-ID: <20070205183232.GA9183@moooo.ath.cx> URL: https://gitlist.dev/e/20070205183232.GA9183%40moooo.ath.cx In-Reply-To: <7vejp4mqad.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > The original examples work perfectly Ok, [..] Ah, so the man page is incomplete? But without HEAD (git merge -m "message" mybranch) the command is ok? It seems to work anyway because merging HEAD just prints "Already up-to-date with ". ``` ## Junio C Hamano, 2007-02-06 02:04 Subject: Re: [PATCH] core-tutorial: git-merge uses -m for commit messages Message-ID: <7v7iuwm48b.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v7iuwm48b.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20070205183232.GA9183@moooo.ath.cx> ``` Matthias Lederhofer writes: > Junio C Hamano wrote: >> The original examples work perfectly Ok, [..] > Ah, so the man page is incomplete? Perhaps, but the older format is not something we would want to recommend to humans, so... > But without HEAD (git merge -m > "message" mybranch) the command is ok? Yes, but ;-). Humans are encouraged to say "git merge " and let fmt-merge-msg to figure out what message to use. If I were updating the end-user tutorial, I would probably recommend people to use the newer format that does not force you to say HEAD. core-tutorial however is meant to talk about how Porcelain scripts do things, and in that sense it makes some sense to demonstrate the use of funny " HEAD " order, only because it is how git-pull invokes "git merge". > It seems to work anyway > because merging HEAD just prints "Already up-to-date with ". Invoking with -m , like this: git merge -m "$msg" HEAD $commit it would try to make an octopus that has the current HEAD (this is given always when you are merging), the HEAD you gave from the command line, and the other $commit. The octopus merge strategy is intelligent enough to notice that the second HEAD is the same as the current HEAD so resulting commit would only have two parents. So it may happen to work, but it is never a good practice. ```