The reverted-cherry mergency 2021.01.26

Timelines can interact in unexpected ways. When seemingly innocent merges yield unexpected results, we call these situations "mergencies" (merge-emergency).

Mergencies can easily arise in real-world situations! They are by no means limited to esoteric edge-cases. If you use git, you better be aware of this issue.

This post will demonstrate the problem with a simple real-world example.

Reverted cherry pick

Suppose that you've worked around a bug in a release branch, and cherry-picked the work-around in main. Later, after implementing a proper fix for the bug in main, you've reverted the work-around, which you no longer want.

Assuming that the work-around and fix do not conflict, what would happen if you would merge the release branch into main? Would the work-around still be reverted?

No! The reverted work-around will resurface if you are on main and git merge the release branch! (if you are skeptical about this claim, see example repo for proof)

Merge in several steps

On the other hand, if you split your merge to several steps, which is often useful for conflict resolution ergonomics, some merge sequences will result with the revert succeeding (demonstrated in example repo).

In such tricky scenarios, at least anything involving reverts, you should verify that the results of the merge or rebase look right.

This situation is real

pajam!

This post was inspired by a real situation encountered during the development of Pajam (btw, if you want to jam musically with your remote friends, give Pajam a try, it's fun!)

Can tooling solve the problem?

A completely different model: Darcs/Pijul

Theoretically, using Darcs or Pijul, alternative version-control systems with radically different branching models would alledgely solve this problem correctly. But contenders don't have the wide adoption nor probably the maturity of git, so I hadn't had the chance to try them out, so I cannot speak about them from experience.

git-imerge

git-imerge does successfully yield the correct merge result in our example. But unfortunately in other cases it yields incorrect merge results!

A new tool?

I'm considering creating a tool for safer merging. My general idea is that when an intermediate merge would change the merge result, it means that there's a manual decision/resolution required. A large obstacle for creating this tool is picking a name.

If such a tool already exists, please let me know!

Notes