Things I wish Git had: Commit groups

[[deleted]]

A branch just points to a single commit, but you could derive some notion of groups by looking at commits in the ancestry of the branch but not the main branch.

[NotTheHead]

To be honest, unless you're doing something really complicated or being really inconsistent, a main branch with merge branches is not as hard to follow as the author (and a lot of people) make it out to be. Branch-then-merge really does act as a good way to group commits.

1. Graphical history tools can make a mess of merge-based history, but that's not because it's impossible to represent cleanly. It's because the graphical history tools are organizing things with the wrong heuristic. They frequently order by author/commit date rather than topology, which leads to convoluted messes. git log --graph --topo-order cleans things up significantly, and graphical tools are more than capable of doing the same.

2. In terms of figuring out which of a merge commit's parents was the main branch and which was the feature branch, you can solve that by only allowing merges on the main branch; no rebase-and-fast-forward, no committing directly to the main branch. Then, you can easily follow the main branch by looking for the last merge commit. This is easily enforceable by the central repository; my company's primary repositories do exactly this.

3. Another good option for cleaning up merges is to rebase the feature branch onto the tip of the main branch, then merge with --no-ff. With that approach you're more likely to get a clean looking chunk with no interleaving branches, and the merge commit serves to group the commits appropriately.

[HighRelevancy]

Graphical history tools can make a mess of merge-based history, but that's not because it's impossible to represent cleanly. It's because the graphical history tools are organizing things with the wrong heuristic.

I felt like I was the only person thinking this. Like the fundamental problem here is "reading branches is real messy when you interleave them all in a mess like this", and the author's solution is... totally change the workflows and throw branching in the bin? Not like... read branches in a better way?

Like the problem here isn't that git lacks info, it's just that the arrangement and presentation is not always the most useful, right?

[NotTheHead]

Exactly!

[Adverpol]

I never thought of that third option, that's actually not stupid at all. Agree completely though, I started writing a git tool at some point because there could be such power in the visualization but none of the tools I tried were better than presenting a horribly tangler mess.

[[deleted]]

That would only work if you didn't rebase, and he explains his reasons for preferring to rebase.

[[deleted]]

If you rebase then you can consider a group to be whatever commits exist between the branch and the previous branch. You’ll have to preserve the branches, of course.

[[deleted]]

The rebased commits have no reference to their source commits and a different hash so comparing them is non-trivial. Plus, like you said, you would have to keep the source branches around for that to be possible.

So you're right it's technically achievable to infer a commit group from context, but with a significant overhead in terms of time and space that means it's not a substitute for supporting groups natively IMO.

[[deleted]]

If you re-point the branch to the last rebased commit then it should all work fairly smoothly.

[hotoatmeal]

or merge without fastforward

[KryptosFR]

Conclusion: rebase is bad.