{"thread":{"id":"52974","subject":"[PATCH 0/2] Fix 2.26.0 rebase regression and documentation shortcoming","startedAt":"2020-03-11T05:13:46Z","lastAt":"2020-03-11T20:18:47Z","messageCount":15,"participants":["Elijah Newren via GitGitGadget","Phillip Wood","Elijah Newren","Junio C Hamano","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"393050","messageId":"pull.722.git.git.1583903621.gitgitgadget@gmail.com","threadId":"52974","inReplyTo":null,"subject":"[PATCH 0/2] Fix 2.26.0 rebase regression and documentation shortcoming","fromName":"Elijah Newren via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2020-03-11T05:13:39Z","receivedAt":"2020-03-11T05:13:46Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"This two commit series addresses two points raised by Peff about rebase\nbackend issues, in reverse order of what he reported. The first is a fix to\na regression in 2.26.0 (when 2.26.0-rc0 added the dropping of commits which\nbecome empty, if the last commit in the series was the one that became empty\nthe rebase would complete without cleaning out state files), and the other\nis just a documentation update about a backend difference that we were\npreviously unaware of.\n\nThe first patch is a one-line fix to the merge backend. The second patch\ncould probably do with a fix to the apply backend but I instead only updated\nthe documentation to note this issue in order to minimize the risk with the\n2.26.0 release.\n\nElijah Newren (2):\n  sequencer: clear CHERRY_PICK_HEAD upon dropping a become-empty commit\n  git-rebase.txt: highlight backend differences with commit rewording\n\n Documentation/git-rebase.txt | 10 ++++++++++\n sequencer.c                  |  1 +\n 2 files changed, 11 insertions(+)\n\n\nbase-commit: b4374e96c84ed9394fed363973eb540da308ed4f\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-722%2Fnewren%2Frebase-fixups-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-722/newren/rebase-fixups-v1\nPull-Request: https://github.com/git/git/pull/722\n-- \ngitgitgadget\n"},{"id":"393051","messageId":"132f769adb0a34e74b6c237ff84bf8b624ea0d9f.1583903621.git.gitgitgadget@gmail.com","threadId":"52974","inReplyTo":"pull.722.git.git.1583903621.gitgitgadget@gmail.com","subject":"[PATCH 1/2] sequencer: clear CHERRY_PICK_HEAD upon dropping a become-empty commit","fromName":"Elijah Newren via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2020-03-11T05:13:40Z","receivedAt":"2020-03-11T05:13:48Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"From: Elijah Newren <newren@gmail.com>\n\nIn commit e98c4269c8 (\"rebase (interactive-backend): fix handling of\ncommits that become empty\", 2020-02-15), the merge backend was changed\nto drop commits that did not start empty but became so after being\napplied (because their changes were a subset of what was already\nupstream).  This new code path did not need to go through the process of\ncreating a commit, since we were dropping the commit instead.\nUnfortunately, this also means we bypassed the clearing of the\nCHERRY_PICK_HEAD file, which if there were no further commits to\ncherry-pick would mean that the rebase would end but assume there was\nstill an operation in progress.  Ensure that we clear CHERRY_PICK_HEAD\nwhen we decide to drop the commit.\n\nSigned-off-by: Elijah Newren <newren@gmail.com>\n---\n sequencer.c | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/sequencer.c b/sequencer.c\nindex 7477b15422a..8b4e0200c5f 100644\n--- a/sequencer.c\n+++ b/sequencer.c\n@@ -1957,6 +1957,7 @@ static int do_pick_commit(struct repository *r,\n \t\tflags |= ALLOW_EMPTY;\n \t} else if (allow == 2) {\n \t\tdrop_commit = 1;\n+\t\tunlink(git_path_cherry_pick_head(r));\n \t\tfprintf(stderr,\n \t\t\t_(\"dropping %s %s -- patch contents already upstream\\n\"),\n \t\t\toid_to_hex(&commit->object.oid), msg.subject);\n-- \ngitgitgadget\n\n"},{"id":"393052","messageId":"12932b847ef9d6c60ed338f68d4a32706d68891d.1583903621.git.gitgitgadget@gmail.com","threadId":"52974","inReplyTo":"pull.722.git.git.1583903621.gitgitgadget@gmail.com","subject":"[PATCH 2/2] git-rebase.txt: highlight backend differences with commit rewording","fromName":"Elijah Newren via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2020-03-11T05:13:41Z","receivedAt":"2020-03-11T05:13:50Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"From: Elijah Newren <newren@gmail.com>\n\nAs noted by Junio:\n    Back when \"git am\" was written, it was not considered a bug that the\n    \"git am --resolved\" option did not offer the user a chance to update\n    the log message to match the adjustment of the code the user made,\n    but honestly, I'd have to say that it is a bug in \"git am\" in that\n    over time it wasn't adjusted to the new world order where we\n    encourage users to describe what they did when the automation\n    hiccuped by opening an editor.  These days, even when automation\n    worked well (e.g. a clean auto-merge with \"git merge\"), we open an\n    editor.  The world has changed, and so should the expectations.\n\nJunio also suggested providing a workaround such as allowing --no-edit\ntogether with git rebase --continue, but that should probably be done in\na patch after the git-2.26.0 release.  For now, just document the known\ndifference in the Behavioral Differences section.\n\nSigned-off-by: Elijah Newren <newren@gmail.com>\n---\n Documentation/git-rebase.txt | 10 ++++++++++\n 1 file changed, 10 insertions(+)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 8c1f4b82680..f7a6033607f 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -699,6 +699,16 @@ suffer from the same shortcoming.  (See\n https://lore.kernel.org/git/20200207132152.GC2868@szeder.dev/ for\n details.)\n \n+Commit Rewording\n+~~~~~~~~~~~~~~~~\n+\n+When a conflict occurs while rebasing, rebase stops and asks the user\n+to resolve.  Since the user may need to make notable changes while\n+resolving conflicts, after conflicts are resolved and the user has run\n+`git rebase --continue`, the rebase should open an editor and ask the\n+user to update the commit message.  The merge backend does this, while\n+the apply backend blindly applies the original commit message.\n+\n Miscellaneous differences\n ~~~~~~~~~~~~~~~~~~~~~~~~~\n \n-- \ngitgitgadget\n"},{"id":"393057","messageId":"94eec36b-581a-17eb-7aeb-2d24c90b8e73@gmail.com","threadId":"52974","inReplyTo":"132f769adb0a34e74b6c237ff84bf8b624ea0d9f.1583903621.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 1/2] sequencer: clear CHERRY_PICK_HEAD upon dropping a become-empty commit","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2020-03-11T10:30:43Z","receivedAt":"2020-03-11T10:30:48Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Elijah\n\nOn 11/03/2020 05:13, Elijah Newren via GitGitGadget wrote:\n> From: Elijah Newren <newren@gmail.com>\n> \n> In commit e98c4269c8 (\"rebase (interactive-backend): fix handling of\n> commits that become empty\", 2020-02-15), the merge backend was changed\n> to drop commits that did not start empty but became so after being\n> applied (because their changes were a subset of what was already\n> upstream).  This new code path did not need to go through the process of\n> creating a commit, since we were dropping the commit instead.\n> Unfortunately, this also means we bypassed the clearing of the\n> CHERRY_PICK_HEAD file, which if there were no further commits to\n> cherry-pick would mean that the rebase would end but assume there was\n> still an operation in progress.  Ensure that we clear CHERRY_PICK_HEAD\n> when we decide to drop the commit.\n\nThanks for fixing this, it needs to clean up MERGE_MSG as well though\n\nBest Wishes\n\nPhillip\n\n> Signed-off-by: Elijah Newren <newren@gmail.com>\n> ---\n>   sequencer.c | 1 +\n>   1 file changed, 1 insertion(+)\n> \n> diff --git a/sequencer.c b/sequencer.c\n> index 7477b15422a..8b4e0200c5f 100644\n> --- a/sequencer.c\n> +++ b/sequencer.c\n> @@ -1957,6 +1957,7 @@ static int do_pick_commit(struct repository *r,\n>   \t\tflags |= ALLOW_EMPTY;\n>   \t} else if (allow == 2) {\n>   \t\tdrop_commit = 1;\n> +\t\tunlink(git_path_cherry_pick_head(r));\n>   \t\tfprintf(stderr,\n>   \t\t\t_(\"dropping %s %s -- patch contents already upstream\\n\"),\n>   \t\t\toid_to_hex(&commit->object.oid), msg.subject);\n> \n"},{"id":"393077","messageId":"pull.722.v2.git.git.1583940623.gitgitgadget@gmail.com","threadId":"52974","inReplyTo":"pull.722.git.git.1583903621.gitgitgadget@gmail.com","subject":"[PATCH v2 0/2] Fix 2.26.0 rebase regression and documentation shortcoming","fromName":"Elijah Newren via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2020-03-11T15:30:21Z","receivedAt":"2020-03-11T15:30:28Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"This two commit series addresses two points raised by Peff about rebase\nbackend issues. The first is a two-line fix to a regression in 2.26.0 (when\n\"the eighth batch for 2.26.0\" added the dropping of commits which become\nempty, if the last commit in the series was the one that became empty the\nrebase would complete without cleaning out state files), and the other is\njust a documentation update about a backend difference that we were\npreviously unaware of.\n\nChanges since v1:\n\n * Clean out any MERGE_MSG file in addition to CHERRY_PICK_HEAD, and add a\n   test\n\nElijah Newren (2):\n  sequencer: clear state upon dropping a become-empty commit\n  git-rebase.txt: highlight backend differences with commit rewording\n\n Documentation/git-rebase.txt | 10 ++++++++++\n sequencer.c                  |  2 ++\n t/t3424-rebase-empty.sh      |  8 ++++++++\n 3 files changed, 20 insertions(+)\n\n\nbase-commit: b4374e96c84ed9394fed363973eb540da308ed4f\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-722%2Fnewren%2Frebase-fixups-v2\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-722/newren/rebase-fixups-v2\nPull-Request: https://github.com/git/git/pull/722\n\nRange-diff vs v1:\n\n 1:  132f769adb0 ! 1:  84b89d78435 sequencer: clear CHERRY_PICK_HEAD upon dropping a become-empty commit\n     @@ -1,6 +1,6 @@\n      Author: Elijah Newren <newren@gmail.com>\n      \n     -    sequencer: clear CHERRY_PICK_HEAD upon dropping a become-empty commit\n     +    sequencer: clear state upon dropping a become-empty commit\n      \n          In commit e98c4269c8 (\"rebase (interactive-backend): fix handling of\n          commits that become empty\", 2020-02-15), the merge backend was changed\n     @@ -9,10 +9,10 @@\n          upstream).  This new code path did not need to go through the process of\n          creating a commit, since we were dropping the commit instead.\n          Unfortunately, this also means we bypassed the clearing of the\n     -    CHERRY_PICK_HEAD file, which if there were no further commits to\n     -    cherry-pick would mean that the rebase would end but assume there was\n     -    still an operation in progress.  Ensure that we clear CHERRY_PICK_HEAD\n     -    when we decide to drop the commit.\n     +    CHERRY_PICK_HEAD and MERGE_MSG files, which if there were no further\n     +    commits to cherry-pick would mean that the rebase would end but assume\n     +    there was still an operation in progress.  Ensure that we clear such\n     +    state files when we decide to drop the commit.\n      \n          Signed-off-by: Elijah Newren <newren@gmail.com>\n      \n     @@ -24,6 +24,24 @@\n       \t} else if (allow == 2) {\n       \t\tdrop_commit = 1;\n      +\t\tunlink(git_path_cherry_pick_head(r));\n     ++\t\tunlink(git_path_merge_msg(r));\n       \t\tfprintf(stderr,\n       \t\t\t_(\"dropping %s %s -- patch contents already upstream\\n\"),\n       \t\t\toid_to_hex(&commit->object.oid), msg.subject);\n     +\n     + diff --git a/t/t3424-rebase-empty.sh b/t/t3424-rebase-empty.sh\n     + --- a/t/t3424-rebase-empty.sh\n     + +++ b/t/t3424-rebase-empty.sh\n     +@@\n     + \ttest_cmp expect actual\n     + '\n     + \n     ++test_expect_success 'rebase --merge does not leave state laying around' '\n     ++\tgit checkout -B testing localmods~2 &&\n     ++\tgit rebase --merge upstream &&\n     ++\n     ++\ttest_path_is_missing .git/CHERRY_PICK_HEAD &&\n     ++\ttest_path_is_missing .git/MERGE_MSG\n     ++'\n     ++\n     + test_done\n 2:  12932b847ef = 2:  6d51cff41d9 git-rebase.txt: highlight backend differences with commit rewording\n\n-- \ngitgitgadget\n"},{"id":"393080","messageId":"84b89d7843527d7b1f3e00f122dc1e82f1ced381.1583940623.git.gitgitgadget@gmail.com","threadId":"52974","inReplyTo":"pull.722.v2.git.git.1583940623.gitgitgadget@gmail.com","subject":"[PATCH v2 1/2] sequencer: clear state upon dropping a become-empty commit","fromName":"Elijah Newren via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2020-03-11T15:30:22Z","receivedAt":"2020-03-11T15:30:33Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"From: Elijah Newren <newren@gmail.com>\n\nIn commit e98c4269c8 (\"rebase (interactive-backend): fix handling of\ncommits that become empty\", 2020-02-15), the merge backend was changed\nto drop commits that did not start empty but became so after being\napplied (because their changes were a subset of what was already\nupstream).  This new code path did not need to go through the process of\ncreating a commit, since we were dropping the commit instead.\nUnfortunately, this also means we bypassed the clearing of the\nCHERRY_PICK_HEAD and MERGE_MSG files, which if there were no further\ncommits to cherry-pick would mean that the rebase would end but assume\nthere was still an operation in progress.  Ensure that we clear such\nstate files when we decide to drop the commit.\n\nSigned-off-by: Elijah Newren <newren@gmail.com>\n---\n sequencer.c             | 2 ++\n t/t3424-rebase-empty.sh | 8 ++++++++\n 2 files changed, 10 insertions(+)\n\ndiff --git a/sequencer.c b/sequencer.c\nindex 7477b15422a..e528225e787 100644\n--- a/sequencer.c\n+++ b/sequencer.c\n@@ -1957,6 +1957,8 @@ static int do_pick_commit(struct repository *r,\n \t\tflags |= ALLOW_EMPTY;\n \t} else if (allow == 2) {\n \t\tdrop_commit = 1;\n+\t\tunlink(git_path_cherry_pick_head(r));\n+\t\tunlink(git_path_merge_msg(r));\n \t\tfprintf(stderr,\n \t\t\t_(\"dropping %s %s -- patch contents already upstream\\n\"),\n \t\t\toid_to_hex(&commit->object.oid), msg.subject);\ndiff --git a/t/t3424-rebase-empty.sh b/t/t3424-rebase-empty.sh\nindex 98fc2a558a0..e1e30517ea6 100755\n--- a/t/t3424-rebase-empty.sh\n+++ b/t/t3424-rebase-empty.sh\n@@ -123,4 +123,12 @@ test_expect_success 'rebase --interactive uses default of --empty=ask' '\n \ttest_cmp expect actual\n '\n \n+test_expect_success 'rebase --merge does not leave state laying around' '\n+\tgit checkout -B testing localmods~2 &&\n+\tgit rebase --merge upstream &&\n+\n+\ttest_path_is_missing .git/CHERRY_PICK_HEAD &&\n+\ttest_path_is_missing .git/MERGE_MSG\n+'\n+\n test_done\n-- \ngitgitgadget\n\n"},{"id":"393082","messageId":"6d51cff41d9ee312a0d9ae3308546284ead1d4c6.1583940623.git.gitgitgadget@gmail.com","threadId":"52974","inReplyTo":"pull.722.v2.git.git.1583940623.gitgitgadget@gmail.com","subject":"[PATCH v2 2/2] git-rebase.txt: highlight backend differences with commit rewording","fromName":"Elijah Newren via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2020-03-11T15:30:23Z","receivedAt":"2020-03-11T15:30:33Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"From: Elijah Newren <newren@gmail.com>\n\nAs noted by Junio:\n    Back when \"git am\" was written, it was not considered a bug that the\n    \"git am --resolved\" option did not offer the user a chance to update\n    the log message to match the adjustment of the code the user made,\n    but honestly, I'd have to say that it is a bug in \"git am\" in that\n    over time it wasn't adjusted to the new world order where we\n    encourage users to describe what they did when the automation\n    hiccuped by opening an editor.  These days, even when automation\n    worked well (e.g. a clean auto-merge with \"git merge\"), we open an\n    editor.  The world has changed, and so should the expectations.\n\nJunio also suggested providing a workaround such as allowing --no-edit\ntogether with git rebase --continue, but that should probably be done in\na patch after the git-2.26.0 release.  For now, just document the known\ndifference in the Behavioral Differences section.\n\nSigned-off-by: Elijah Newren <newren@gmail.com>\n---\n Documentation/git-rebase.txt | 10 ++++++++++\n 1 file changed, 10 insertions(+)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 8c1f4b82680..f7a6033607f 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -699,6 +699,16 @@ suffer from the same shortcoming.  (See\n https://lore.kernel.org/git/20200207132152.GC2868@szeder.dev/ for\n details.)\n \n+Commit Rewording\n+~~~~~~~~~~~~~~~~\n+\n+When a conflict occurs while rebasing, rebase stops and asks the user\n+to resolve.  Since the user may need to make notable changes while\n+resolving conflicts, after conflicts are resolved and the user has run\n+`git rebase --continue`, the rebase should open an editor and ask the\n+user to update the commit message.  The merge backend does this, while\n+the apply backend blindly applies the original commit message.\n+\n Miscellaneous differences\n ~~~~~~~~~~~~~~~~~~~~~~~~~\n \n-- \ngitgitgadget\n"},{"id":"393078","messageId":"20200311163454.GC27893@coredump.intra.peff.net","threadId":"52974","inReplyTo":"84b89d7843527d7b1f3e00f122dc1e82f1ced381.1583940623.git.gitgitgadget@gmail.com","subject":"Re: [PATCH v2 1/2] sequencer: clear state upon dropping a become-empty commit","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-03-11T16:34:54Z","receivedAt":"2020-03-11T16:34:57Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 11, 2020 at 03:30:22PM +0000, Elijah Newren via GitGitGadget wrote:\n\n> From: Elijah Newren <newren@gmail.com>\n> \n> In commit e98c4269c8 (\"rebase (interactive-backend): fix handling of\n> commits that become empty\", 2020-02-15), the merge backend was changed\n> to drop commits that did not start empty but became so after being\n> applied (because their changes were a subset of what was already\n> upstream).  This new code path did not need to go through the process of\n> creating a commit, since we were dropping the commit instead.\n> Unfortunately, this also means we bypassed the clearing of the\n> CHERRY_PICK_HEAD and MERGE_MSG files, which if there were no further\n> commits to cherry-pick would mean that the rebase would end but assume\n> there was still an operation in progress.  Ensure that we clear such\n> state files when we decide to drop the commit.\n\nThanks, I can confirm this fixes my case (which is not surprising, as it\nis the same as your new test). The patch looks good. Two minor comments\nbelow, but I doubt there is anything to act on.\n\n> diff --git a/sequencer.c b/sequencer.c\n> index 7477b15422a..e528225e787 100644\n> --- a/sequencer.c\n> +++ b/sequencer.c\n> @@ -1957,6 +1957,8 @@ static int do_pick_commit(struct repository *r,\n>  \t\tflags |= ALLOW_EMPTY;\n>  \t} else if (allow == 2) {\n>  \t\tdrop_commit = 1;\n> +\t\tunlink(git_path_cherry_pick_head(r));\n> +\t\tunlink(git_path_merge_msg(r));\n>  \t\tfprintf(stderr,\n>  \t\t\t_(\"dropping %s %s -- patch contents already upstream\\n\"),\n>  \t\t\toid_to_hex(&commit->object.oid), msg.subject);\n\nIt feels like the set of paths to be cleaned up would probably exist\nelsewhere in a helper function for cleaning up real cherry-picks. But\nI'll defer to your expertise there, as I don't know the sequencer code\nvery well.\n\n> +test_expect_success 'rebase --merge does not leave state laying around' '\n> +\tgit checkout -B testing localmods~2 &&\n> +\tgit rebase --merge upstream &&\n> +\n> +\ttest_path_is_missing .git/CHERRY_PICK_HEAD &&\n> +\ttest_path_is_missing .git/MERGE_MSG\n> +'\n\nThis could check the output of git-status to avoid poking around in the\n.git directory itself. But I doubt that the exact filenames are going to\nchange, and parsing the output of status is its own problem (I don't\nthink we give this \"state\" info in a machine-readable way).\n\n-Peff\n"},{"id":"393079","messageId":"20200311163643.GD27893@coredump.intra.peff.net","threadId":"52974","inReplyTo":"6d51cff41d9ee312a0d9ae3308546284ead1d4c6.1583940623.git.gitgitgadget@gmail.com","subject":"Re: [PATCH v2 2/2] git-rebase.txt: highlight backend differences with commit rewording","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-03-11T16:36:43Z","receivedAt":"2020-03-11T16:36:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 11, 2020 at 03:30:23PM +0000, Elijah Newren via GitGitGadget wrote:\n\n> From: Elijah Newren <newren@gmail.com>\n> \n> As noted by Junio:\n>     Back when \"git am\" was written, it was not considered a bug that the\n>     \"git am --resolved\" option did not offer the user a chance to update\n>     the log message to match the adjustment of the code the user made,\n>     but honestly, I'd have to say that it is a bug in \"git am\" in that\n>     over time it wasn't adjusted to the new world order where we\n>     encourage users to describe what they did when the automation\n>     hiccuped by opening an editor.  These days, even when automation\n>     worked well (e.g. a clean auto-merge with \"git merge\"), we open an\n>     editor.  The world has changed, and so should the expectations.\n> \n> Junio also suggested providing a workaround such as allowing --no-edit\n> together with git rebase --continue, but that should probably be done in\n> a patch after the git-2.26.0 release.  For now, just document the known\n> difference in the Behavioral Differences section.\n\nThanks. With the earlier bug fix and this documentation change, I'm OK\nwith keeping the merge-backend transition in v2.26.0. This change\n_might_ cause problems in somebody's script, but that will be true\nwhether it comes in 2.26 or 2.27, and I think it's clear this is the end\nstate we want to get to eventually.\n\n-Peff\n"},{"id":"393061","messageId":"CABPp-BFtspDhSherYyhH-Aw=oPLzCiGfbMUiLPB0n1rnzV3k0Q@mail.gmail.com","threadId":"52974","inReplyTo":"20200311163454.GC27893@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] sequencer: clear state upon dropping a become-empty commit","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-03-11T17:16:22Z","receivedAt":"2020-03-11T17:16:28Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Mar 11, 2020 at 9:34 AM Jeff King <peff@peff.net> wrote:\n>\n> On Wed, Mar 11, 2020 at 03:30:22PM +0000, Elijah Newren via GitGitGadget wrote:\n>\n> > From: Elijah Newren <newren@gmail.com>\n> >\n> > In commit e98c4269c8 (\"rebase (interactive-backend): fix handling of\n> > commits that become empty\", 2020-02-15), the merge backend was changed\n> > to drop commits that did not start empty but became so after being\n> > applied (because their changes were a subset of what was already\n> > upstream).  This new code path did not need to go through the process of\n> > creating a commit, since we were dropping the commit instead.\n> > Unfortunately, this also means we bypassed the clearing of the\n> > CHERRY_PICK_HEAD and MERGE_MSG files, which if there were no further\n> > commits to cherry-pick would mean that the rebase would end but assume\n> > there was still an operation in progress.  Ensure that we clear such\n> > state files when we decide to drop the commit.\n>\n> Thanks, I can confirm this fixes my case (which is not surprising, as it\n> is the same as your new test). The patch looks good. Two minor comments\n> below, but I doubt there is anything to act on.\n>\n> > diff --git a/sequencer.c b/sequencer.c\n> > index 7477b15422a..e528225e787 100644\n> > --- a/sequencer.c\n> > +++ b/sequencer.c\n> > @@ -1957,6 +1957,8 @@ static int do_pick_commit(struct repository *r,\n> >               flags |= ALLOW_EMPTY;\n> >       } else if (allow == 2) {\n> >               drop_commit = 1;\n> > +             unlink(git_path_cherry_pick_head(r));\n> > +             unlink(git_path_merge_msg(r));\n> >               fprintf(stderr,\n> >                       _(\"dropping %s %s -- patch contents already upstream\\n\"),\n> >                       oid_to_hex(&commit->object.oid), msg.subject);\n>\n> It feels like the set of paths to be cleaned up would probably exist\n> elsewhere in a helper function for cleaning up real cherry-picks. But\n> I'll defer to your expertise there, as I don't know the sequencer code\n> very well.\n\nYeah, I was looking for something like that but instead found the\nunlink() directives for cleaning up various state files scattered\nthroughout the code.  I think sequencer.c is in need of some cleaning\nup; the slow transition from \"do what shell does, now work both with\nan external shell and some pieces built in, now move slightly more\ntowards being built-in\" seems to have left a lot of artifacts around\nand made it a bit unwieldy.\n\nAs another anecdote along these lines, I really wanted to do my demo\nof an in-memory rebase with the existing builtin/rebase.c and\nsequencer.c but it was too much effort even for just a demo to rip out\nthe unwanted parts, so I did my in-memory rebase demo in a completely\ndifferent file (https://github.com/newren/git/blob/git-merge-2020-demo/builtin/fast-rebase.c)\n\nI'm not sure deferring to my expertise with sequencer.c makes sense,\nsince you have about twice as many commits to sequencer.c as me.  But\nI was deferring to Phillip and he commented on my v1 and seemed happy\n(other than my missing handling of MERGE_MSG).\n\n> > +test_expect_success 'rebase --merge does not leave state laying around' '\n> > +     git checkout -B testing localmods~2 &&\n> > +     git rebase --merge upstream &&\n> > +\n> > +     test_path_is_missing .git/CHERRY_PICK_HEAD &&\n> > +     test_path_is_missing .git/MERGE_MSG\n> > +'\n>\n> This could check the output of git-status to avoid poking around in the\n> .git directory itself. But I doubt that the exact filenames are going to\n> change, and parsing the output of status is its own problem (I don't\n> think we give this \"state\" info in a machine-readable way).\n\nYeah, it's not clear to me what's best either.  When I was testing my\nchanges locally I was checking status output.  However, after creating\nthe fix and deciding to add a regression test, I switched to checking\nfor the existence of those files basically for the reasons you\nmention, despite knowing I'm only testing for certain state files\nrather than testing that git in general doesn't think it's still in\nthe middle of some operation.\n"},{"id":"393065","messageId":"xmqqwo7qhh45.fsf@gitster.c.googlers.com","threadId":"52974","inReplyTo":"94eec36b-581a-17eb-7aeb-2d24c90b8e73@gmail.com","subject":"Re: [PATCH 1/2] sequencer: clear CHERRY_PICK_HEAD upon dropping a become-empty commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-03-11T18:38:18Z","receivedAt":"2020-03-11T18:38:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood <phillip.wood123@gmail.com> writes:\n\n> Thanks for fixing this, it needs to clean up MERGE_MSG as well though\n>\n> Best Wishes\n>\n> Phillip\n>\n>> Signed-off-by: Elijah Newren <newren@gmail.com>\n>> ---\n>>   sequencer.c | 1 +\n>>   1 file changed, 1 insertion(+)\n>>\n>> diff --git a/sequencer.c b/sequencer.c\n>> index 7477b15422a..8b4e0200c5f 100644\n>> --- a/sequencer.c\n>> +++ b/sequencer.c\n>> @@ -1957,6 +1957,7 @@ static int do_pick_commit(struct repository *r,\n>>   \t\tflags |= ALLOW_EMPTY;\n>>   \t} else if (allow == 2) {\n>>   \t\tdrop_commit = 1;\n>> +\t\tunlink(git_path_cherry_pick_head(r));\n\nWhen this fails for whatever reason, do we need to do something\nspecial?  The same question for MERGE_MSG Phillip mentioned.\n\nThanks, both.\n\n>>   \t\tfprintf(stderr,\n>>   \t\t\t_(\"dropping %s %s -- patch contents already upstream\\n\"),\n>>   \t\t\toid_to_hex(&commit->object.oid), msg.subject);\n>>\n"},{"id":"393071","messageId":"xmqqk13qhfly.fsf@gitster.c.googlers.com","threadId":"52974","inReplyTo":"20200311163643.GD27893@coredump.intra.peff.net","subject":"Re: [PATCH v2 2/2] git-rebase.txt: highlight backend differences with commit rewording","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-03-11T19:10:49Z","receivedAt":"2020-03-11T19:10:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Thanks. With the earlier bug fix and this documentation change, I'm OK\n> with keeping the merge-backend transition in v2.26.0. This change\n> _might_ cause problems in somebody's script, but that will be true\n> whether it comes in 2.26 or 2.27, and I think it's clear this is the end\n> state we want to get to eventually.\n\nI am OK either way, so let's take these two, plus the \"don't i18n\nthe literals that must be given as option values\" patch from Jiang,\nand discard the \"let's delay the inevitable to buy some time\" patch.\n\nI merged the last one locally to 'next' already but I haven't pushed\nthe result out, so it is still possible to back out ;-)\n"},{"id":"393085","messageId":"20200311192720.GB27978@coredump.intra.peff.net","threadId":"52974","inReplyTo":"xmqqwo7qhh45.fsf@gitster.c.googlers.com","subject":"Re: [PATCH 1/2] sequencer: clear CHERRY_PICK_HEAD upon dropping a become-empty commit","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-03-11T19:27:20Z","receivedAt":"2020-03-11T19:27:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 11, 2020 at 11:38:18AM -0700, Junio C Hamano wrote:\n\n> >>   \t} else if (allow == 2) {\n> >>   \t\tdrop_commit = 1;\n> >> +\t\tunlink(git_path_cherry_pick_head(r));\n> \n> When this fails for whatever reason, do we need to do something\n> special?  The same question for MERGE_MSG Phillip mentioned.\n\nI don't think there's much we _can_ do. The other call-sites seem to\njust ignore failures. I suspect turning those into unlink_or_warn()\nwould be a good idea (and should be safe; it treats ENOENT as a noop, so\nanything it reports should be an actual error worthy of the user's\nattention).\n\nBut probably it would make sense to do that consistently for all of\nthose calls, and that doesn't need to be part of the 2.26 fixup.\n\n-Peff\n"},{"id":"393088","messageId":"20200311193317.GC27978@coredump.intra.peff.net","threadId":"52974","inReplyTo":"CABPp-BFtspDhSherYyhH-Aw=oPLzCiGfbMUiLPB0n1rnzV3k0Q@mail.gmail.com","subject":"Re: [PATCH v2 1/2] sequencer: clear state upon dropping a become-empty commit","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-03-11T19:33:17Z","receivedAt":"2020-03-11T19:33:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 11, 2020 at 10:16:22AM -0700, Elijah Newren wrote:\n\n> > It feels like the set of paths to be cleaned up would probably exist\n> > elsewhere in a helper function for cleaning up real cherry-picks. But\n> > I'll defer to your expertise there, as I don't know the sequencer code\n> > very well.\n> \n> Yeah, I was looking for something like that but instead found the\n> unlink() directives for cleaning up various state files scattered\n> throughout the code.  I think sequencer.c is in need of some cleaning\n> up; the slow transition from \"do what shell does, now work both with\n> an external shell and some pieces built in, now move slightly more\n> towards being built-in\" seems to have left a lot of artifacts around\n> and made it a bit unwieldy.\n\nOK. As long as you looked and didn't find anything obvious that should\nbe used, I'm content to leave it for a later cleanup (I also looked\nbriefly and didn't find anything useful).\n\n> I'm not sure deferring to my expertise with sequencer.c makes sense,\n> since you have about twice as many commits to sequencer.c as me.  But\n> I was deferring to Phillip and he commented on my v1 and seemed happy\n> (other than my missing handling of MERGE_MSG).\n\nHeh, all memories of sequencer.c have been wiped from my memory. I\nthought you might have looked at it more recently because of this rebase\nbackend work, but I guess that didn't involve poking at the sequencer\ninternals much.\n\n> > This could check the output of git-status to avoid poking around in the\n> > .git directory itself. But I doubt that the exact filenames are going to\n> > change, and parsing the output of status is its own problem (I don't\n> > think we give this \"state\" info in a machine-readable way).\n> \n> Yeah, it's not clear to me what's best either.  When I was testing my\n> changes locally I was checking status output.  However, after creating\n> the fix and deciding to add a regression test, I switched to checking\n> for the existence of those files basically for the reasons you\n> mention, despite knowing I'm only testing for certain state files\n> rather than testing that git in general doesn't think it's still in\n> the middle of some operation.\n\nI did just double check that \"git status\" has no way to produce a\nmachine-readable version of the data. That might be worth addressing in\ngeneral[1], but I think what you have here is a good test for now.\n\n-Peff\n\n[1] In particular, I think that git-prompt.sh reimplements some of this\n    logic, and I would be surprised if there wasn't some weird corner\n    case where they differ. The prompt code does try to avoid invoking\n    subprocesses for efficiency, but I imagine we're running git-status\n    already to get the dirty state.\n"},{"id":"393091","messageId":"xmqq5zfahcgt.fsf@gitster.c.googlers.com","threadId":"52974","inReplyTo":"20200311192720.GB27978@coredump.intra.peff.net","subject":"Re: [PATCH 1/2] sequencer: clear CHERRY_PICK_HEAD upon dropping a become-empty commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-03-11T20:18:42Z","receivedAt":"2020-03-11T20:18:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Mar 11, 2020 at 11:38:18AM -0700, Junio C Hamano wrote:\n>\n>> >>   \t} else if (allow == 2) {\n>> >>   \t\tdrop_commit = 1;\n>> >> +\t\tunlink(git_path_cherry_pick_head(r));\n>> \n>> When this fails for whatever reason, do we need to do something\n>> special?  The same question for MERGE_MSG Phillip mentioned.\n>\n> I don't think there's much we _can_ do. The other call-sites seem to\n> just ignore failures. I suspect turning those into unlink_or_warn()\n> would be a good idea (and should be safe; it treats ENOENT as a noop, so\n> anything it reports should be an actual error worthy of the user's\n> attention).\n>\n> But probably it would make sense to do that consistently for all of\n> those calls, and that doesn't need to be part of the 2.26 fixup.\n\nYes, I think that is a sensible way forward.\n\nThanks, all.\n"}]}