{"thread":{"id":"6690","subject":"[PATCH] core-tutorial: git-merge uses -m for commit messages","startedAt":"2007-02-05T11:34:39Z","lastAt":"2007-02-06T02:04:04Z","messageCount":4,"participants":["Matthias Lederhofer","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"33623","messageId":"20070205113439.GA27077@moooo.ath.cx","threadId":"6690","inReplyTo":null,"subject":"[PATCH] core-tutorial: git-merge uses -m for commit messages","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-02-05T11:34:39Z","receivedAt":"2007-02-05T11:34:39Z","isPatch":true,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Signed-off-by: Matthias Lederhofer <matled@gmx.net>\n---\n Documentation/core-tutorial.txt |   12 ++++++------\n 1 files changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt\nindex 9c28bea..6f30e0a 100644\n--- a/Documentation/core-tutorial.txt\n+++ b/Documentation/core-tutorial.txt\n@@ -894,11 +894,11 @@ script called `git merge`, which wants to know which branches you want\n to resolve and what the merge is all about:\n \n ------------\n-$ git merge \"Merge work in mybranch\" HEAD mybranch\n+$ git merge -m \"Merge work in mybranch\" HEAD mybranch\n ------------\n \n-where the first argument is going to be used as the commit message if\n-the merge can be resolved automatically.\n+The `-m` options specifies the commit message to be used for the merge commit\n+(in case it is created).\n \n Now, in this case we've intentionally created a situation where the\n merge will need to be fixed up by hand, though, so git will do as much\n@@ -981,7 +981,7 @@ resolve to get the \"upstream changes\" back to your branch.\n \n ------------\n $ git checkout mybranch\n-$ git merge \"Merge upstream changes.\" HEAD master\n+$ git merge -m \"Merge upstream changes.\" HEAD master\n ------------\n \n This outputs something like this (the actual commit object names\n@@ -1623,8 +1623,8 @@ in both of them.  You could merge in 'diff-fix' first and then\n 'commit-fix' next, like this:\n \n ------------\n-$ git merge 'Merge fix in diff-fix' master diff-fix\n-$ git merge 'Merge fix in commit-fix' master commit-fix\n+$ git merge -m 'Merge fix in diff-fix' master diff-fix\n+$ git merge -m 'Merge fix in commit-fix' master commit-fix\n ------------\n \n Which would result in:\n-- \n1.5.0.rc3.544.g79b8\n"},{"id":"33645","messageId":"7vejp4mqad.fsf@assigned-by-dhcp.cox.net","threadId":"6690","inReplyTo":"20070205113439.GA27077@moooo.ath.cx","subject":"Re: [PATCH] core-tutorial: git-merge uses -m for commit messages","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-05T18:07:38Z","receivedAt":"2007-02-05T18:07:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Lederhofer <matled@gmx.net> writes:\n\n> Signed-off-by: Matthias Lederhofer <matled@gmx.net>\n> ---\n>  Documentation/core-tutorial.txt |   12 ++++++------\n>  1 files changed, 6 insertions(+), 6 deletions(-)\n>\n> diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt\n> index 9c28bea..6f30e0a 100644\n> --- a/Documentation/core-tutorial.txt\n> +++ b/Documentation/core-tutorial.txt\n> @@ -894,11 +894,11 @@ script called `git merge`, which wants to know which branches you want\n>  to resolve and what the merge is all about:\n>  \n>  ------------\n> -$ git merge \"Merge work in mybranch\" HEAD mybranch\n> +$ git merge -m \"Merge work in mybranch\" HEAD mybranch\n>  ------------\n\nUnfortunately it needs more than that.\n\nThe funny command argument order in the original example was the\ncommand line format that has been in use internally for a long\ntime:  merge <msg> HEAD <other commit>.\n\nThe human-accessible form that uses -m in front of <msg> does\nnot need the second argument that always must match the current\ncommit (it always must match so there is no point saying it).\n\nThe original examples work perfectly Ok, and you broke it -- if\nyou are doing '-m' you need to remove HEAD (and master in later\nones) from the command line.\n"},{"id":"33646","messageId":"20070205183232.GA9183@moooo.ath.cx","threadId":"6690","inReplyTo":"7vejp4mqad.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] core-tutorial: git-merge uses -m for commit messages","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-02-05T18:32:32Z","receivedAt":"2007-02-05T18:32:32Z","isPatch":true,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> The original examples work perfectly Ok, [..]\nAh, so the man page is incomplete?  But without HEAD (git merge -m\n\"message\" mybranch) the command is ok?  It seems to work anyway\nbecause merging HEAD just prints \"Already up-to-date with <commit>\".\n"},{"id":"33682","messageId":"7v7iuwm48b.fsf@assigned-by-dhcp.cox.net","threadId":"6690","inReplyTo":"20070205183232.GA9183@moooo.ath.cx","subject":"Re: [PATCH] core-tutorial: git-merge uses -m for commit messages","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-06T02:04:04Z","receivedAt":"2007-02-06T02:04:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Lederhofer <matled@gmx.net> writes:\n\n> Junio C Hamano <junkio@cox.net> wrote:\n>> The original examples work perfectly Ok, [..]\n> Ah, so the man page is incomplete?\n\nPerhaps, but the older format is not something we would want to\nrecommend to humans, so...\n\n> But without HEAD (git merge -m\n> \"message\" mybranch) the command is ok?\n\nYes, but ;-).\n\nHumans are encouraged to say \"git merge <that-branch>\" and let\nfmt-merge-msg to figure out what message to use.\n\nIf I were updating the end-user tutorial, I would probably\nrecommend people to use the newer format that does not force you\nto say HEAD.  core-tutorial however is meant to talk about how\nPorcelain scripts do things, and in that sense it makes some\nsense to demonstrate the use of funny \"<msg> HEAD <commit>\"\norder, only because it is how git-pull invokes \"git merge\".\n\n> It seems to work anyway\n> because merging HEAD just prints \"Already up-to-date with <commit>\".\n\nInvoking with -m <msg>, like this:\n\n\tgit merge -m \"$msg\" HEAD $commit\n\nit would try to make an octopus that has the current HEAD (this\nis given always when you are merging), the HEAD you gave from\nthe command line, and the other $commit.  The octopus merge\nstrategy is intelligent enough to notice that the second HEAD is\nthe same as the current HEAD so resulting commit would only have\ntwo parents.  So it may happen to work, but it is never a good\npractice.\n"}]}