> I desperately wish git had a "group commits" feature that let me manage a cluster of related commits as a single commit for the purposes of history-viewing, reverting, and cherry-picking.
Merge commits work fine for most of that, you just have to adapt to merge UX/commands:
--first-parent (to git log, git annotate, etc) gives you clean history viewing of just your "groups" (your merge commits).
--first-parent even works for bisect allowing you start by figuring out which merge commit brought in a change (and then dig into the merge branch itself if needed as a second bisect).
You can revert or cherry pick merges if you provide the -m (mainline) flag to tell it which parent to consider the mainline (usually the first parent, but not always depending on your intended revert/cherry-pick; it complicates what you need to know about the revert/cherry-pick, but if you are in the process of revert/cherry-picking you should already be figuring out what your mainline is and expecting some possible complications).
I think sometimes the only "problem" with Merge commits is too few pretty UX tools default to a --first-parent view of the git graph and don't themselves provide good tool for picking that -m (mainline) for revert/cherry-pick.
I think it is an interesting tools problem: making interesting graph diagrams of the full git log graph is a fun and interesting problem and often looks great in screenshots, but rarely is a particularly "useful" view to most users. It's not as "fun", doesn't produce as many shiny/colorful screenshots, to build --first-parent views by default and introduce (and test) graph drill-down based user experiences.
Merge commits work fine for most of that, you just have to adapt to merge UX/commands:
--first-parent (to git log, git annotate, etc) gives you clean history viewing of just your "groups" (your merge commits).
--first-parent even works for bisect allowing you start by figuring out which merge commit brought in a change (and then dig into the merge branch itself if needed as a second bisect).
You can revert or cherry pick merges if you provide the -m (mainline) flag to tell it which parent to consider the mainline (usually the first parent, but not always depending on your intended revert/cherry-pick; it complicates what you need to know about the revert/cherry-pick, but if you are in the process of revert/cherry-picking you should already be figuring out what your mainline is and expecting some possible complications).
I think sometimes the only "problem" with Merge commits is too few pretty UX tools default to a --first-parent view of the git graph and don't themselves provide good tool for picking that -m (mainline) for revert/cherry-pick.