git rebase -i -autosquash conflict

Question

git is giving me a major headache when using --fixup and --autosquash. I would like to give two examples, one working perfectly fine and the other being a mess. (git version 2.

Answer 1

git is giving me a major headache when using --fixup and --autosquash.

Beware there is another case, when using git rebase --autosquash, of headache.

Git 2.20 (Q4 2018) just fixed a bug related to autosquash: "git rebase -i" did not clear the state files correctly when a run of "squash/fixup" is aborted and then the user manually amended the commit instead, which has been corrected.

See commit 10d2f35, commit 2f3eb68 (31 Aug 2018) by Johannes Schindelin (dscho). ^{(Merged by Junio C Hamano -- gitster -- in commit 87ae8a1, 24 Sep 2018)}

rebase -i --autosquash: demonstrate a problem skipping the last squash

The git commit --squash command can be used not only to amend commit messages and changes, but also to record notes for an upcoming rebase.

For example, when the author information of a given commit is incorrect, a user might call git commit --allow-empty -m "Fix author" --squash , to remind them to fix that during the rebase. When the editor would pop up, the user would simply delete the commit message to abort the rebase at this stage, fix the author information, and continue with git rebase --skip. (This is a real-world example from the rebase of Git for Windows onto v2.19.0-rc1.)

However, there is a bug in git rebase that will cause the squash message not to be forgotten in this case. It will therefore be reused in the next fixup/squash chain (if any).

rebase -i: be careful to wrap up fixup/squash chains

When an interactive rebase was stopped at the end of a fixup/squash chain, the user might have edited the commit manually before continuing (with either git rebase --skip or git rebase --continue, it does not really matter which).

We need to be very careful to wrap up the fixup/squash chain also in this scenario: otherwise the next fixup/squash chain would try to pick up where the previous one was left.

---

Before Git 2.27 (Q2 2020), "rebase -i" segfaulted when rearranging a sequence that has a fix-up that applies another fix-up (which may or may not be a fix-up of yet another step).

See commit 02471e7 (09 May 2020) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit a2a0942, 14 May 2020)}

rebase --autosquash: fix a potential segfault

^{Reported-by: Paul Ganssle
Helped-by: Jeff King
Signed-off-by: Johannes Schindelin}

When rearranging the todo list so that the fixups/squashes are reordered just after the commits they intend to fix up, we use two arrays to maintain that list: next and tail.

The idea is that next[i], if set to a non-negative value, contains the index of the item that should be rearranged just after the ith item.

To avoid having to walk the entire next chain when appending another fixup/squash, we also store the end of the next chain in tail[i].

The logic we currently use to update these array items is based on the assumption that given a fixup/squash item at index i, we just found the index i2 indicating the first item in that fixup chain.

However, as reported by Paul Ganssle, that need not be true: the special form fixup! is allowed to point to another fixup commit in the middle of the fixup chain.

Example:

* 0192a To fixup
* 02f12 fixup! To fixup
* 03763 fixup! To fixup
* 04ecb fixup! 02f12

Note how the fourth commit targets the second commit, which is already a fixup that targets the first commit.

Previously, we would update next and tail under our assumption that every fixup! commit would find the start of the fixup!/squash! chain.
This would lead to a segmentation fault because we would actually end up with a next[i] pointing to a fixup! but the corresponding tail[i] pointing nowhere, which would the lead to a segmentation fault.

Let's fix this by inserting, rather than appending, the item.

In other words, if we make a given line successor of another line, we do not simply forget any previously set successor of the latter, but make it a successor of the former.

In the above example, at the point when we insert 04ecb just after 02f12, 03763 would already be recorded as a successor of 04ecb, and we now "squeeze in" 04ecb.

To complete the idea, we now no longer assume that next[i] pointing to a line means that last[i] points to a line, too.
Instead, we extend the concept of last to cover also partial fixup!/squash! chains, i.e. chains starting in the middle of a larger such chain.

In the above example, after processing all lines, last[0] (corresponding to 0192a) would point to 03763, which indeed is the end of the overall fixup! chain, and last[1] (corresponding to 02f12) would point to 04ecb (which is the last fixup! targeting 02f12, but it has 03763 as successor, i.e. it is not the end of overall fixup! chain).