# first-class merges and cover letters

DevFeed: [first-class merges and cover letters](<https://devfeed.tech/articles/first-class-merges-and-cover-letters-36222.md>)

Original publisher: [Read original article](<https://dotat.at/@/2025-09-11-cover-letter.html>)

Published: 2025-09-11T01:26:47Z

Content type: opinion

Language: en

Sources: [Tony Finch's blog](<https://devfeed.tech/sources/tony-finch-s-blog.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [version-control](<https://devfeed.tech/topics/version-control.md>), [Development](<https://devfeed.tech/topics/development.md>), [pull-requests](<https://devfeed.tech/topics/pull-requests.md>), [Code review](<https://devfeed.tech/topics/code-review.md>)

Tags: [branch](<https://devfeed.tech/tags/branch.md>), [git](<https://devfeed.tech/tags/git.md>), [merge](<https://devfeed.tech/tags/merge.md>), [review](<https://devfeed.tech/tags/review.md>), [version-control](<https://devfeed.tech/tags/version-control.md>), [workflow](<https://devfeed.tech/tags/workflow.md>)

## AI overview

This commentary examines shortcomings in Git branches and common merge and rebase workflows. It argues that improving merges, rather than branches alone, could make branch-based development more effective, while considering trade-offs between detailed history and clean logical changes.

## Source excerpt

Although it looks really good, I have not yet tried the Jujutsu (jj) version control system, mainly because it's not yet clearly superior to Magit. But I have been following jj discussions with great interest. One of the things that jj has not yet tackled is how to do better than git refs / branches / tags. As I underestand it, jj currently has something like Mercurial bookmarks, which are more like raw git ref plumbing than a high-level porcelain feature. In particular, jj lacks signed or annotated tags, and it doesn't have branch names that always automatically refer to the tip. This is clearly a temporary state of affairs because jj is still incomplete and under development and these gaps are going to be filled. But the discussions have led me to think about how git's branches are unsatisfactory, and what could be done to improve them. branch merge rebase squash fork cover letters previous branch workflow questions branch One of the huge improvements in git compared to Subversion was git's support for merges. Subversion proudly advertised its support for lightweight branches, but a branch is not very useful if you can't merge it: an un-mergeable branch is not a tool you can use to help with work-in-progress development. The point of this anecdote is to illustrate that rather than trying to make branches better, we should try to make merges better and branches will get better as a consequence. Let's consider a few common workflows and how git makes them all unsatisfactory in various ways. Skip to cover letters and previous branch below where I eventually get to the point. merge A basic merge workflow is, create a feature branch hack, hack, review, hack, approve merge back to the trunk The main problem is when it comes to the merge, there may be conflicts due to concurrent work on the trunk. Git encourages you to resolve conflicts while creating the merge commit, which tends to bypass the normal review process. Git also gives you an ugly useless canned commit messa