4 ms·
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 w
by adtac 8y ago
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?
- jonahx 8y agoBecause 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.
- adtac 8y agoThat 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.
- jonahx 8y agoNot 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.