Re:Write good git commit messages
by adtac on Wednesday December 12, 2018 @09:20AM
(#18664056)
I fail to see how that would be useful. Commits are supposed to be atomic, self-contained changes by themselves. More often than not, I see merge commits only when people abuse commits for temporary state of work (with useless commit messages like "fix" and "temp"). Instead, if each commit did one thing and one thing only, why would you need a visual indicator that these set of commits came from a particular branch?
[ Parent
| on HN ]
Because they are logically grouped and that grouping is often more important than the commits themselves -- together, they accomplish a higher-level goal.
You want both that goal and the individual tasks which achieved it to be visible.
That information can and should be a part of the commit body. An extra commit just for that information is, in my opinion, a hack and a workaround.
I guess we have fundamental differences on how a tree should be structured. It's more of a DAG in your case, but I prefer to keep a tree a tree.
Not sure I follow your argument. How would you put information about the semantic meaning of a series of commits into "the commit body"?
The only point I'm making essentially is that "the commit" is too granular to capture all the information you need about your work and its history. You need some kind of grouping mechanism as well. It doesn't have to be merge commits, necessarily. But as I understood it, your original argument was that "there is no need for anything higher level than a commit." But there clearly is imo.
If you tag HEAD after each merged PR you can still see which commits belong together, they'll be between two tags.