{"thread":{"id":"50292","subject":"Q: What happened to \"--no-commit\" merges?","startedAt":"2019-01-22T21:02:53Z","lastAt":"2019-02-21T17:50:40Z","messageCount":11,"participants":["Ulrich Windl","Elijah Newren","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"367360","messageId":"5C47833C020000A10002F499@gwsmtp1.uni-regensburg.de","threadId":"50292","inReplyTo":null,"subject":"Q: What happened to \"--no-commit\" merges?","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2019-01-22T20:55:24Z","receivedAt":"2019-01-22T21:02:53Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"Hi!\n\nUsing git version 2.16.4 on OpenSUSE Leap 15.0, it seems that \"--no-commit\" no\nlonger does what it did before (AFAIR, but I mostly did --no-ff merges in\nSLES11):\nLike this (sorry German):\n\n> git merge --no-commit local/f-linux-firefox \nAktualisiere 520aaae..c11e3da\nFast-forward\n bin/fval.xsl | 133 +++++++++++++++++++++++++----------------------------------\n 1 file changed, 57 insertions(+), 76 deletions(-)\n\n> git status\nAuf Branch f-linux-firefox\nnichts zu committen, Arbeitsverzeichnis unverändert\n\n### \"nothing to commit\"\ngit log indicates the changes were committed already\n\nReading\nhttps://stackoverflow.com/questions/8640887/git-merge-without-auto-commit it\nseems that without \"--no-ff\" this ioption is effectively ignored.\nIf so, I suggest to tell the user that --no-commit is useless in this case, and\nlet him confirm that he/she wants the changes (merge) to be committed (despite\nof --no-commit).\n\nRegards,\nUlrich\n\n\n"},{"id":"367377","messageId":"CABPp-BFGfWPAwKLMMMLdLu856UvrrSMYjYWXeVUxEqpspBxbsA@mail.gmail.com","threadId":"50292","inReplyTo":"5C47833C020000A10002F499@gwsmtp1.uni-regensburg.de","subject":"Re: Q: What happened to \"--no-commit\" merges?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-01-22T21:29:02Z","receivedAt":"2019-01-22T21:29:16Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hello,\n\nOn Tue, Jan 22, 2019 at 1:05 PM Ulrich Windl\n wrote:\n>\n> Hi!\n>\n> Using git version 2.16.4 on OpenSUSE Leap 15.0, it seems that \"--no-commit\" no\n> longer does what it did before (AFAIR, but I mostly did --no-ff merges in\n> SLES11):\n> Like this (sorry German):\n>\n> > git merge --no-commit local/f-linux-firefox\n> Aktualisiere 520aaae..c11e3da\n> Fast-forward\n\nAh, a fast foward, so there was nothing to commit; it could simply\nupdate the branch to include commits that already existed.\n\n> bin/fval.xsl | 133 +++++++++++++++++++++++++----------------------------------\n> 1 file changed, 57 insertions(+), 76 deletions(-)\n>\n> > git status\n> Auf Branch f-linux-firefox\n> nichts zu committen, Arbeitsverzeichnis unverändert\n>\n> ### \"nothing to commit\"\n> git log indicates the changes were committed already\n\nIndeed; the changes were committed before you ran \"git merge\"; they\nwere all part of the local/f-linux-firefox branch.\n\n> Reading\n> https://stackoverflow.com/questions/8640887/git-merge-without-auto-commit it\n> seems that without \"--no-ff\" this ioption is effectively ignored.\n> If so, I suggest to tell the user that --no-commit is useless in this case, and\n> let him confirm that he/she wants the changes (merge) to be committed (despite\n> of --no-commit).\n\n--no-commit, to me, means don't create any new commits. But you had a\ncase where there was no need to create a any new commits: your branch\n(f-linux-firefox, I think?) had no commits that the other branch\n(local/f-linux-firefox) lacked, but the other branch had at least one\nyou lacked. So, merging could be done by just moving your branch\npointer to include all those existing commits.\n\nIf you want the branch to not get updated, then yes you'd need both\n--no-ff and --no-commit in some cases. But that's always been true.\nIt's possible in the past that you just didn't run into those cases.\n\nNow, if you're suggesting that --no-commit should imply --no-ff,\nthat's interesting. However, you are fundamentally changing the\noperation at that point by making it so that a merge commit will be\ncreated when the user runs `git commit` at the end -- it's not clear\nto me that users will see a merge commit as wanted or needed and\nhaving --no-commit imply that option might break expectations. I'd be\nmore inclined to tell users who want --no-ff behavor to use that flag\nand/or set the merge.ff config setting to false.\n\nAlternatively, we could update the documentation to point out this\nspecial case under --no-commit to point out that when an ff-update\noccurs no commit creation is involved and thus --no-commit has no\neffect. Would that help?\n\n\nElijah\n"},{"id":"367406","messageId":"5C481202020000A10002F4AE@gwsmtp1.uni-regensburg.de","threadId":"50292","inReplyTo":"CABPp-BFGfWPAwKLMMMLdLu856UvrrSMYjYWXeVUxEqpspBxbsA@mail.gmail.com","subject":"Antw: Re: Q: What happened to \"--no-commit\" merges?","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2019-01-23T07:04:34Z","receivedAt":"2019-01-23T07:04:41Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":">>> Elijah Newren schrieb am 22.01.2019 um 22:29 in\nNachricht\n:\n> Hello,\n> \n> On Tue, Jan 22, 2019 at 1:05 PM Ulrich Windl\n> wrote:\n>>\n>> Hi!\n>>\n>> Using git version 2.16.4 on OpenSUSE Leap 15.0, it seems that \"--no-commit\"\n\n> no\n>> longer does what it did before (AFAIR, but I mostly did --no-ff merges in\n>> SLES11):\n>> Like this (sorry German):\n>>\n>> > git merge --no-commit local/f-linux-firefox\n>> Aktualisiere 520aaae..c11e3da\n>> Fast-forward\n> \n> Ah, a fast foward, so there was nothing to commit; it could simply\n> update the branch to include commits that already existed.\n> \n>> bin/fval.xsl | 133 \n> +++++++++++++++++++++++++----------------------------------\n>> 1 file changed, 57 insertions(+), 76 deletions(-)\n>>\n>> > git status\n>> Auf Branch f-linux-firefox\n>> nichts zu committen, Arbeitsverzeichnis unverändert\n>>\n>> ### \"nothing to commit\"\n>> git log indicates the changes were committed already\n> \n> Indeed; the changes were committed before you ran \"git merge\"; they\n> were all part of the local/f-linux-firefox branch.\n\nActually no: The changes were on a different local \"remote\" branch; otherwise\nI wouldn't need the merge, I guess\n\n> \n>> Reading\n>> https://stackoverflow.com/questions/8640887/git-merge-without-auto-commit\nit\n>> seems that without \"--no-ff\" this ioption is effectively ignored.\n\nNote: If you see the number of upvotes to the answer there, it seems I'm not\nthe only one who got confused. ;-)\n\n>> If so, I suggest to tell the user that --no-commit is useless in this case,\n\n> and\n>> let him confirm that he/she wants the changes (merge) to be committed \n> (despite\n>> of --no-commit).\n> \n> --no-commit, to me, means don't create any new commits. But you had a\n> case where there was no need to create a any new commits: your branch\n> (f-linux-firefox, I think?) had no commits that the other branch\n> (local/f-linux-firefox) lacked, but the other branch had at least one\n> you lacked. So, merging could be done by just moving your branch\n> pointer to include all those existing commits.\n\nIs moving commits from one branch to to another done without any new commit?\nJust updating the refs, or what? I didn't know that.\n\n> \n> If you want the branch to not get updated, then yes you'd need both\n> --no-ff and --no-commit in some cases. But that's always been true.\n> It's possible in the past that you just didn't run into those cases.\n\nSo it seems a commit is something other than I'd expected: To me anything that\nchanges what \"git log\" outputs is a commit ;-) Or anything that chenges the\nreflog...\n\n> \n> Now, if you're suggesting that --no-commit should imply --no-ff,\n> that's interesting. However, you are fundamentally changing the\n> operation at that point by making it so that a merge commit will be\n> created when the user runs `git commit` at the end -- it's not clear\n> to me that users will see a merge commit as wanted or needed and\n> having --no-commit imply that option might break expectations. I'd be\n> more inclined to tell users who want --no-ff behavor to use that flag\n> and/or set the merge.ff config setting to false.\n\nNo, it seems I didn't realize that a fast-forward actually is without a\ncommit.\n\n\n> \n> Alternatively, we could update the documentation to point out this\n> special case under --no-commit to point out that when an ff-update\n> occurs no commit creation is involved and thus --no-commit has no\n> effect. Would that help?\n\nMaybe (I'm unsure where the concepts are described best to check the current\nversion(s)) try to explain the concepts of \"commit\" and \"fast forward\" in some\ngreater detail. Maybe I was just expecting the wrong things to happen behind\nthe scenes. Maybe add a statement like \"fast-forwards never create a new\ncommit, so --no-commit doesn't make sense when fast-forwarding.\"\n\nThanks for the explanations.\n\nRegards,\nUlrich\n\n\n"},{"id":"369543","messageId":"20190218184147.7563-1-newren@gmail.com","threadId":"50292","inReplyTo":"5C481202020000A10002F4AE@gwsmtp1.uni-regensburg.de","subject":"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-02-18T18:41:47Z","receivedAt":"2019-02-18T18:41:59Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Ulrich,\n\nSorry for the late reply...\n\nOn Tue, Jan 22, 2019 at 11:04 PM Ulrich Windl wrote:\n> >>> Elijah Newren schrieb am 22.01.2019 um 22:29 in\n> Nachricht\n> > On Tue, Jan 22, 2019 at 1:05 PM Ulrich Windl\n> > wrote:\n> >>\n> >> Using git version 2.16.4 on OpenSUSE Leap 15.0, it seems that \"--no-commit\"\n> >> no\n> >> longer does what it did before (AFAIR, but I mostly did --no-ff merges in\n> >> SLES11):\n> >>\n> >> > git merge --no-commit local/f-linux-firefox\n> >> Aktualisiere 520aaae..c11e3da\n> >> Fast-forward\n....\n> > Indeed; the changes were committed before you ran \"git merge\"; they\n> > were all part of the local/f-linux-firefox branch.\n>\n> Actually no: The changes were on a different local \"remote\" branch; otherwise\n> I wouldn't need the merge, I guess\n\nYes, they were on a different branch, but since the commits already exist they don't need to be created again. The current branch can just be updated from the current commit to the commit on the end of the other branch. No merge is needed because the histories of the two branches have not diverged, so the merge short-circuits itself (doing what is sometimes called a \"fast-forward merge\" instead and avoiding almost all the normal merge logic).\n\n> >> Reading\n> >> https://stackoverflow.com/questions/8640887/git-merge-without-auto-commit\n> it\n> >> seems that without \"--no-ff\" this ioption is effectively ignored.\n>\n> Note: If you see the number of upvotes to the answer there, it seems I'm not\n> the only one who got confused. ;-)\n\nIndeed, and looking at that stackoverflow post, it makes it clear that the manpage is actually misleading. I'll post a patch to correct it.\n\n> Is moving commits from one branch to to another done without any new commit?\n> Just updating the refs, or what? I didn't know that.\n\nIf the two branches have not diverged at all, and only one side has some commits that the other doesn't, then indeed there is no need for creating any new commits. If the histories have diverged, then you need to create a merge commit and have a real merge.\n\n> > If you want the branch to not get updated, then yes you'd need both\n> > --no-ff and --no-commit in some cases. But that's always been true.\n> > It's possible in the past that you just didn't run into those cases.\n>\n> So it seems a commit is something other than I'd expected: To me anything that\n> changes what \"git log\" outputs is a commit ;-) Or anything that chenges the\n> reflog...\n\nA commit is an object that records its parents (most commits have exactly one parent), its author, its committer, a commit message, and the tree involved. Creating a new commit is a common reason to change the reflog and would cause git log to have more output for subsequent invocations. Most merges will of necessity create a merge commit, to reflect that diverging histories have been merged (and such a commit will have more than one parent, one for each branch being merged). But, as noted above, if histories haven't diverged then we don't need a new multi-parent commit; we can just short-circuit the merge logic and use the existing commits on the other branch.\n\n> > Alternatively, we could update the documentation to point out this\n> > special case under --no-commit to point out that when an ff-update\n> > occurs no commit creation is involved and thus --no-commit has no\n> > effect. Would that help?\n>\n> Maybe (I'm unsure where the concepts are described best to check the current\n> version(s)) try to explain the concepts of \"commit\" and \"fast forward\" in some\n> greater detail. Maybe I was just expecting the wrong things to happen behind\n> the scenes. Maybe add a statement like \"fast-forwards never create a new\n> commit, so --no-commit doesn't make sense when fast-forwarding.\"\n>\n> Thanks for the explanations.\n\nHopefully the patch below answers what you originally needed to know and prevents others from running into similar problems.\n\nThanks,\nElijah\n\n-- 8< --\nSubject: [PATCH] merge-options.txt: correct wording of --no-commit option\n\nThe former wording implied that --no-commit would always cause the\nmerge operation to abort and allow the user to make further changes\nand/or provide a special commit message for the merge commit. This\nis not the case for fast-forward merges, as there is no merge commit\nto create. Without a merge commit, there is no place where it makes\nsense to \"stop the merge and allow the user to tweak changes\"; doing\nthat would require a full rebase of some sort.\n\nModify the wording to correctly address fast-forward cases as well,\nand suggest using --no-ff with --no-commit if the point is to ensure\nthat the merge aborts.\n\nReported-by: Ulrich Windl \nSigned-off-by: Elijah Newren \n---\n Documentation/merge-options.txt | 12 +++++++++---\n 1 file changed, 9 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt\nindex c2a263ba74..d1061b8cf7 100644\n--- a/Documentation/merge-options.txt\n+++ b/Documentation/merge-options.txt\n@@ -3,9 +3,15 @@\n \tPerform the merge and commit the result. This option can\n \tbe used to override --no-commit.\n +\n-With --no-commit perform the merge but pretend the merge\n-failed and do not autocommit, to give the user a chance to\n-inspect and further tweak the merge result before committing.\n+With --no-commit perform the merge and stop just before creating\n+a merge commit, to give the user a chance to inspect and further\n+tweak the merge result before committing.\n++\n+Note that fast-forward updates do not need to create a merge\n+commit and therefore there is no way to stop those merges with\n+--no-commit. Thus, if you want to ensure your branch is not\n+changed or updated by the merge command, use --no-ff with\n+--no-commit.\n \n --edit::\n -e::\n-- \n2.21.0.rc1.264.g6c9e06a32d\n\n"},{"id":"369614","messageId":"5C6BAA4E020000A10002FBFF@gwsmtp1.uni-regensburg.de","threadId":"50292","inReplyTo":"0A3130DD0200005B824A10E1@gwsmtp1.uni-regensburg.de","subject":"Antw: Antw:","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2019-02-19T07:03:42Z","receivedAt":"2019-02-19T07:03:51Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":">>> Elijah Newren schrieb am 18.02.2019 um 19:41 in\nNachricht\n<20190218184147.7563-1-newren@gmail.com>:\n> Hi Ulrich,\n> \n> Sorry for the late reply...\n\nNo problem, thanks for the explanation. I'll \"fast forward\" directly to the\npatch below and comment inline: -- Ulrich\n\n[...]\n> ‑‑ 8< ‑‑\n> Subject: [PATCH] merge‑options.txt: correct wording of ‑‑no‑commit option\n> \n> The former wording implied that ‑‑no‑commit would always cause the\n> merge operation to abort and allow the user to make further changes\n\nI think \"abort\" is not the perfect word, because the merge would rather be\n\"paused for commit\" in my understanding; a \"git merge --abort\" is different,\nright?\n\n> and/or provide a special commit message for the merge commit. This\n> is not the case for fast‑forward merges, as there is no merge commit\n> to create. Without a merge commit, there is no place where it makes\n> sense to \"stop the merge and allow the user to tweak changes\"; doing\n> that would require a full rebase of some sort.\n\n...and before trying the merge it's not always obvious whether the merge will\nbe fast-forward type or not. So actually the outcome of --no-commit depends on\nthe conents being merged, not on the command line options.\n\n> \n> Modify the wording to correctly address fast‑forward cases as well,\n> and suggest using ‑‑no‑ff with ‑‑no‑commit if the point is to ensure\n> that the merge aborts.\n> \n> Reported‑by: Ulrich Windl \n> Signed‑off‑by: Elijah Newren \n> ‑‑‑\n> Documentation/merge‑options.txt | 12 +++++++++‑‑‑\n> 1 file changed, 9 insertions(+), 3 deletions(‑)\n> \n> diff ‑‑git a/Documentation/merge‑options.txt\nb/Documentation/merge‑options.txt\n> index c2a263ba74..d1061b8cf7 100644\n> ‑‑‑ a/Documentation/merge‑options.txt\n> +++ b/Documentation/merge‑options.txt\n> @@ ‑3,9 +3,15 @@\n> \tPerform the merge and commit the result. This option can\n> \tbe used to override ‑‑no‑commit.\n> +\n> ‑With ‑‑no‑commit perform the merge but pretend the merge\n> ‑failed and do not autocommit, to give the user a chance to\n> ‑inspect and further tweak the merge result before committing.\n> +With ‑‑no‑commit perform the merge and stop just before creating\n> +a merge commit, to give the user a chance to inspect and further\n> +tweak the merge result before committing.\n> ++\n> +Note that fast‑forward updates do not need to create a merge\n> +commit and therefore there is no way to stop those merges with\n> +‑‑no‑commit. Thus, if you want to ensure your branch is not\n> +changed or updated by the merge command, use ‑‑no‑ff with\n> +‑‑no‑commit.\n> \n> ‑‑edit::\n> ‑e::\n> ‑‑ \n> 2.21.0.rc1.264.g6c9e06a32d\n\n\n\n"},{"id":"369653","messageId":"20190219170709.25463-1-newren@gmail.com","threadId":"50292","inReplyTo":"5C6BAA4E020000A10002FBFF@gwsmtp1.uni-regensburg.de","subject":"[PATCH v2] merge-options.txt: correct wording of --no-commit option","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-02-19T17:07:09Z","receivedAt":"2019-02-19T17:07:20Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"The former wording implied that --no-commit would always cause the\nmerge operation to \"pause\" and allow the user to make further changes\nand/or provide a special commit message for the merge commit. This\nis not the case for fast-forward merges, as there is no merge commit\nto create. Without a merge commit, there is no place where it makes\nsense to \"stop the merge and allow the user to tweak changes\"; doing\nthat would require a full rebase of some sort.\n\nSince users may be unaware of whether their branches have diverged or\nnot, modify the wording to correctly address fast-forward cases as well\nand suggest using --no-ff with --no-commit if the point is to ensure\nthat the merge stops before completing.\n\nReported-by: Ulrich Windl \nSigned-off-by: Elijah Newren \n---\nChanges since v1:\n - Tweaked commit message\n\n Documentation/merge-options.txt | 12 +++++++++---\n 1 file changed, 9 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt\nindex c2a263ba74..d1061b8cf7 100644\n--- a/Documentation/merge-options.txt\n+++ b/Documentation/merge-options.txt\n@@ -3,9 +3,15 @@\n \tPerform the merge and commit the result. This option can\n \tbe used to override --no-commit.\n +\n-With --no-commit perform the merge but pretend the merge\n-failed and do not autocommit, to give the user a chance to\n-inspect and further tweak the merge result before committing.\n+With --no-commit perform the merge and stop just before creating\n+a merge commit, to give the user a chance to inspect and further\n+tweak the merge result before committing.\n++\n+Note that fast-forward updates do not need to create a merge\n+commit and therefore there is no way to stop those merges with\n+--no-commit. Thus, if you want to ensure your branch is not\n+changed or updated by the merge command, use --no-ff with\n+--no-commit.\n \n --edit::\n -e::\n-- \n2.21.0.rc1.264.g6c9e06a32d\n\n"},{"id":"369661","messageId":"xmqqk1hv1sms.fsf@gitster-ct.c.googlers.com","threadId":"50292","inReplyTo":"20190219170709.25463-1-newren@gmail.com","subject":"Re: [PATCH v2] merge-options.txt: correct wording of --no-commit option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-02-19T19:32:27Z","receivedAt":"2019-02-19T19:32:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren writes:\n\n> +With --no-commit perform the merge and stop just before creating\n> +a merge commit, to give the user a chance to inspect and further\n> +tweak the merge result before committing.\n> ++\n> +Note that fast-forward updates do not need to create a merge\n> +commit and therefore there is no way to stop those merges with\n> +--no-commit. Thus, if you want to ensure your branch is not\n> +changed or updated by the merge command, use --no-ff with\n> +--no-commit.\n\nWhile the above is an improvement (so I'll queue it on 'pu' not to\nlose sight of it), I find the use of \"do not need to\" above somewhat\nmisleading. It solicits a reaction \"ok, we know it does not need\nto, but it could prepare to create one to allow us to further muck\nwith it, no?\".\n\nIOW, a fast-forward by definition does not create a merge by itself,\nso there is nowhere to stop during a creation of a merge. So at\nleast:\n\n\ts/do not need to/do not/\n\nIt also may be a good idea to consider detecting this case and be a\nbit more helpful, perhaps with end-user experience looking like...\n\n $ git checkout master^0\n $ git merge --no-commit next\n Updating 0d0ac3826a..ee538a81fe\n Fast-forward\n ...diffstat follows here...\n hint: merge completed without creating a commit.\n hint: if you wanted to prepare for a manually tweaked merge,\n hint: do \"git reset --keep ORIG_HEAD\" followed by\n hint: \"git merge --no-ff --no-commit next\".\n\nor even\n\n $ git checkout master^0\n $ git merge --no-commit next\n warning: defaulting to --no-ff, given a --no-commit request\n Automatic merge went well; stopped before committing as requested\n hint: if you'd rather have a fast-forward without creating a commit,\n hint: do \"git reset --keep next\" now.\n\nI do not have a strong preference among three (the third option\nbeing not doing anything), but if pressed, I'd say that the last one\nmight be the most user-friendly, even though it feels a bit too\nmagical and trying to be smarter than its own good.\n\nIn any case, the hint for the \"recovery\" procedure needs to be\ncarefully written.\n"},{"id":"369674","messageId":"CABPp-BGGujXxdmdv0P+TwHwwKaK2maA6rJ7=WpiJYq7ZZivkpw@mail.gmail.com","threadId":"50292","inReplyTo":"xmqqk1hv1sms.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v2] merge-options.txt: correct wording of --no-commit option","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-02-19T22:31:50Z","receivedAt":"2019-02-19T22:32:04Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Feb 19, 2019 at 11:32 AM Junio C Hamano wrote:\n> Elijah Newren writes:\n>\n> > +With --no-commit perform the merge and stop just before creating\n> > +a merge commit, to give the user a chance to inspect and further\n> > +tweak the merge result before committing.\n> > ++\n> > +Note that fast-forward updates do not need to create a merge\n> > +commit and therefore there is no way to stop those merges with\n> > +--no-commit. Thus, if you want to ensure your branch is not\n> > +changed or updated by the merge command, use --no-ff with\n> > +--no-commit.\n>\n> While the above is an improvement (so I'll queue it on 'pu' not to\n> lose sight of it), I find the use of \"do not need to\" above somewhat\n> misleading. It solicits a reaction \"ok, we know it does not need\n> to, but it could prepare to create one to allow us to further muck\n> with it, no?\".\n>\n> IOW, a fast-forward by definition does not create a merge by itself,\n> so there is nowhere to stop during a creation of a merge. So at\n> least:\n>\n> s/do not need to/do not/\n\nYes, I agree that's a good change. I'll wait a few days for other\nfeedback and resend with that and any other changes.\n\n> It also may be a good idea to consider detecting this case and be a\n> bit more helpful, perhaps with end-user experience looking like...\n>\n> $ git checkout master^0\n> $ git merge --no-commit next\n> Updating 0d0ac3826a..ee538a81fe\n> Fast-forward\n> ...diffstat follows here...\n> hint: merge completed without creating a commit.\n> hint: if you wanted to prepare for a manually tweaked merge,\n> hint: do \"git reset --keep ORIG_HEAD\" followed by\n> hint: \"git merge --no-ff --no-commit next\".\n>\n> or even\n>\n> $ git checkout master^0\n> $ git merge --no-commit next\n> warning: defaulting to --no-ff, given a --no-commit request\n> Automatic merge went well; stopped before committing as requested\n> hint: if you'd rather have a fast-forward without creating a commit,\n> hint: do \"git reset --keep next\" now.\n\nGood points. I thought of this last one before sending, though\nwithout pre- and post- warnings/hints; without such text it definitely\nseemed too magical and possibly leading to unexpected surprises in a\ndifferent direction, so I dismissed it without further thought. But\nthe warnings/hints help.\n\n> I do not have a strong preference among three (the third option\n> being not doing anything), but if pressed, I'd say that the last one\n> might be the most user-friendly, even though it feels a bit too\n> magical and trying to be smarter than its own good.\n\nI also lack a strong preference. Maybe mark it #leftoverbits for\nsomeone that does?\n\n> In any case, the hint for the \"recovery\" procedure needs to be\n> carefully written.\n\nYes.\n"},{"id":"369677","messageId":"xmqqo977z9o2.fsf@gitster-ct.c.googlers.com","threadId":"50292","inReplyTo":"CABPp-BGGujXxdmdv0P+TwHwwKaK2maA6rJ7=WpiJYq7ZZivkpw@mail.gmail.com","subject":"Re: [PATCH v2] merge-options.txt: correct wording of --no-commit option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-02-19T22:38:05Z","receivedAt":"2019-02-19T22:38:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren writes:\n\n>> $ git checkout master^0\n>> $ git merge --no-commit next\n>> warning: defaulting to --no-ff, given a --no-commit request\n>> Automatic merge went well; stopped before committing as requested\n>> hint: if you'd rather have a fast-forward without creating a commit,\n>> hint: do \"git reset --keep next\" now.\n>\n> Good points. I thought of this last one before sending, though\n> without pre- and post- warnings/hints; without such text it definitely\n> seemed too magical and possibly leading to unexpected surprises in a\n> different direction, so I dismissed it without further thought. But\n> the warnings/hints help.\n>\n>> I do not have a strong preference among three (the third option\n>> being not doing anything), but if pressed, I'd say that the last one\n>> might be the most user-friendly, even though it feels a bit too\n>> magical and trying to be smarter than its own good.\n>\n> I also lack a strong preference. Maybe mark it #leftoverbits for\n> someone that does?\n\nThis definitely is outside the scope of the documentation update.\n"},{"id":"369694","messageId":"5C6D01C6020000A10002FC4C@gwsmtp1.uni-regensburg.de","threadId":"50292","inReplyTo":"AC7679FC02000011B9FD70CF@gwsmtp1.uni-regensburg.de","subject":"Antw: Re: [PATCH v2] merge-options.txt: correct wording of --no-commit option","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2019-02-20T07:29:10Z","receivedAt":"2019-02-20T07:29:18Z","isPatch":true,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":">>> Junio C Hamano schrieb am 19.02.2019 um 20:32 in\nNachricht\n:\n> Elijah Newren writes:\n> \n>> +With ‑‑no‑commit perform the merge and stop just before creating\n>> +a merge commit, to give the user a chance to inspect and further\n>> +tweak the merge result before committing.\n>> ++\n>> +Note that fast‑forward updates do not need to create a merge\n>> +commit and therefore there is no way to stop those merges with\n>> +‑‑no‑commit. Thus, if you want to ensure your branch is not\n>> +changed or updated by the merge command, use ‑‑no‑ff with\n>> +‑‑no‑commit.\n> \n> While the above is an improvement (so I'll queue it on 'pu' not to\n> lose sight of it), I find the use of \"do not need to\" above somewhat\n> misleading. It solicits a reaction \"ok, we know it does not need\n> to, but it could prepare to create one to allow us to further muck\n> with it, no?\".\n> \n> IOW, a fast‑forward by definition does not create a merge by itself,\n> so there is nowhere to stop during a creation of a merge. So at\n> least:\n> \n> \ts/do not need to/do not/\n\nAgree.\n\n> \n> It also may be a good idea to consider detecting this case and be a\n> bit more helpful, perhaps with end‑user experience looking like...\n> \n> $ git checkout master^0\n> $ git merge ‑‑no‑commit next\n> Updating 0d0ac3826a..ee538a81fe\n> Fast‑forward\n> ...diffstat follows here...\n> hint: merge completed without creating a commit.\n> hint: if you wanted to prepare for a manually tweaked merge,\n> hint: do \"git reset ‑‑keep ORIG_HEAD\" followed by\n> hint: \"git merge ‑‑no‑ff ‑‑no‑commit next\".\n> \n> or even\n> \n> $ git checkout master^0\n> $ git merge ‑‑no‑commit next\n> warning: defaulting to ‑‑no‑ff, given a ‑‑no‑commit request\n> Automatic merge went well; stopped before committing as requested\n> hint: if you'd rather have a fast‑forward without creating a commit,\n> hint: do \"git reset ‑‑keep next\" now.\n> \n> I do not have a strong preference among three (the third option\n> being not doing anything), but if pressed, I'd say that the last one\n> might be the most user‑friendly, even though it feels a bit too\n> magical and trying to be smarter than its own good.\n> \n> In any case, the hint for the \"recovery\" procedure needs to be\n> carefully written.\n\nActually I think if the user specified \"--no-commit\" and the merge turns out\nto be fast-forward, the user could be asked whether to continue or not (instead\nof undoinf afterwards); maybe when entering a response is not possible (batch\nprocessing) the merge should be aborted due to \"--no-commit\" not being possible\n(well actually there would never be a commit, even without that option). The\nproblem is that without prior inspection of the tree you cannot know whether\nthe merge will be fast-forward or not: fast-forward being an optimization (taht\nis enabled by default) makes life more complicated here.\n\nRegards,\nUlrich Windl\n\n"},{"id":"369828","messageId":"20190221175029.26121-1-newren@gmail.com","threadId":"50292","inReplyTo":"20190219170709.25463-1-newren@gmail.com","subject":"[PATCH v3] merge-options.txt: correct wording of --no-commit option","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-02-21T17:50:29Z","receivedAt":"2019-02-21T17:50:40Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"The former wording implied that --no-commit would always cause the\nmerge operation to \"pause\" and allow the user to make further changes\nand/or provide a special commit message for the merge commit. This\nis not the case for fast-forward merges, as there is no merge commit\nto create. Without a merge commit, there is no place where it makes\nsense to \"stop the merge and allow the user to tweak changes\"; doing\nthat would require a full rebase of some sort.\n\nSince users may be unaware of whether their branches have diverged or\nnot, modify the wording to correctly address fast-forward cases as well\nand suggest using --no-ff with --no-commit if the point is to ensure\nthat the merge stops before completing.\n\nReported-by: Ulrich Windl \nSigned-off-by: Elijah Newren \n---\nChanges since v2:\n - Small wording change suggested by Junio (s/do not need to/do not/)\n\n Documentation/merge-options.txt | 11 ++++++++---\n 1 file changed, 8 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt\nindex c2a263ba74..5be89168c6 100644\n--- a/Documentation/merge-options.txt\n+++ b/Documentation/merge-options.txt\n@@ -3,9 +3,14 @@\n \tPerform the merge and commit the result. This option can\n \tbe used to override --no-commit.\n +\n-With --no-commit perform the merge but pretend the merge\n-failed and do not autocommit, to give the user a chance to\n-inspect and further tweak the merge result before committing.\n+With --no-commit perform the merge and stop just before creating\n+a merge commit, to give the user a chance to inspect and further\n+tweak the merge result before committing.\n++\n+Note that fast-forward updates do not create a merge commit and\n+therefore there is no way to stop those merges with --no-commit.\n+Thus, if you want to ensure your branch is not changed or updated\n+by the merge command, use --no-ff with --no-commit.\n \n --edit::\n -e::\n-- \n2.21.0.rc2.262.g736ce73923\n\n"}]}