Fix 2.26.0 rebase regression and documentation shortcoming #722
Conversation
|
/submit |
|
Submitted as pull.722.git.git.1583903621.gitgitgadget@gmail.com |
![gitgitgadget-git[bot]](https://avatars.githubusercontent.com/in/46807?s=60&v=4){kind=small}
In commit e98c426 ("rebase (interactive-backend): fix handling of commits that become empty", 2020-02-15), the merge backend was changed to drop commits that did not start empty but became so after being applied (because their changes were a subset of what was already upstream). This new code path did not need to go through the process of creating a commit, since we were dropping the commit instead. Unfortunately, this also means we bypassed the clearing of the CHERRY_PICK_HEAD and MERGE_MSG files, which if there were no further commits to cherry-pick would mean that the rebase would end but assume there was still an operation in progress. Ensure that we clear such state files when we decide to drop the commit. Signed-off-by: Elijah Newren <newren@gmail.com>
As noted by Junio:
Back when "git am" was written, it was not considered a bug that the
"git am --resolved" option did not offer the user a chance to update
the log message to match the adjustment of the code the user made,
but honestly, I'd have to say that it is a bug in "git am" in that
over time it wasn't adjusted to the new world order where we
encourage users to describe what they did when the automation
hiccuped by opening an editor. These days, even when automation
worked well (e.g. a clean auto-merge with "git merge"), we open an
editor. The world has changed, and so should the expectations.
Junio also suggested providing a workaround such as allowing --no-edit
together with git rebase --continue, but that should probably be done in
a patch after the git-2.26.0 release. For now, just document the known
difference in the Behavioral Differences section.
Signed-off-by: Elijah Newren <newren@gmail.com>
|
@emaste any idea why freebsd_12 is failing? It looks like it received signal 15 ( |
|
There's an issue with FreeBSD VMs used by Cirrus at the moment it seems, see more details at cirruslabs/cirrus-ci-docs#592 We're trying to figure out what's happening. You can try the rerun button on the Cirrus panel. |
|
I'll ignore the FreeBSD one then and just submit... |
|
/submit |
Right, I should have done that right away. That turned the build green. |
|
This patch series was integrated into pu via 958a149. |
|
This patch series was integrated into next via 52a3c30. |
|
This branch is now known as |
|
This patch series was integrated into pu via b4f0038. |
|
This patch series was integrated into next via b4f0038. |
|
This patch series was integrated into master via b4f0038. |
|
Closed via b4f0038. |
This two commit series addresses two points raised by Peff about rebase backend issues. The first is a two-line fix to a regression in 2.26.0 (when "the eighth batch for 2.26.0" added the dropping of commits which become empty, if the last commit in the series was the one that became empty the rebase would complete without cleaning out state files), and the other is just a documentation update about a backend difference that we were previously unaware of.
Changes since v1:
Cc: Phillip Wood phillip.wood123@gmail.com, Jeff King peff@peff.net, Junio C Hamano gitster@pobox.com