does anyone have tips for how to make sense of git merge histories like this? do you use `git log --first-parent`? `git log --topo-order --no-merges`? something else? how can you tell if commit A was merged before or after commit B? what if there are "backwards" merges like in the 3rd screenshot?
(no "just make the history linear” or "merges are bad" takes please)
i think my favourite answer to “how do you make sense of git merge histories" so far is “use git log --merges"
this seems pretty good, but it's hard to get a nice one-line summary of each merge with `--oneline` because the first line of the merge is just something like "Merge pull request #148 from briankassouf/race-detector” (instead of “Add a -race flag to enable Go's race detector on builds" which would be a more useful summary)
(2/?)
@internetionals hmm it seems like an extremely common convention though -- like in the the git project’s repo they format their merge messages very similarly to how github/gitlab do even though they don't use github to merge https://github.com/git/git/commit/340581bcf11bd6e85f87af1d732c898885929e90
and Linux does the same thing. I guess neither of those projects thinks `—oneline` support is important? feels like there's something obvious I"m missing
@b0rk i don’t know if they thought about oneline history. But the convention is that the first line of the commit message is the subject. That should probably be the title of the merge/pull request.
The fact that it’s a merge is more a detail and some random request-id that has no beating without some external system is more something for the footer of a request. Or at best a short preamble like “Pull #123: <title>”.
Julia Evans
Justin Ossevoort