These are only merges - they don't matter. The actual functional commits are excellent beyond anything you would ever find in your company VCS.
[1]: https://euroquis.nl/blabla/2019/08/09/git-alligator.html
https://patchwork.freedesktop.org/series/73884/
With the current kernel development model these aren't recorded in the actual tree, though.
So the best use I've seen for the merge commits are bugtracker task IDs and such.
1. Create a bug fix on the main development branch. eg "master" or equivalent.
This ensures the bug is "resolved" for all new builds and future releases.
2. Apply the fix to the supported release branches. eg v3.12.x, v3.11.x, etc.
This ensures the bug is "resolved" for all new point releases created from those release branches. eg v3.12.1, v3.12.2, etc.
In practise though, does it work well?
I think it could be done a lot differently, and better, but any change requires huge amount of political changes. There's probably ... 2 or 3 teams that would need to approve of any process change, and no one wants to be the one to push changes like this ahead. It's "good enough", even though... we often collectively lose a non-trivial amount of time every week or two or three. We log that "wasted time" in a spreadsheet to make a point of it, but... no one is motivated enough the shepherd the required change process. The devops team would have to change a bunch of their scripts, and the process would need to be coordinated among multiple teams of varying sizes and skills. It is kinda disorganized and nightmarish with... I'm trying to count - there's maybe 20+ devs touching this. I suspect this was 'fine' 10 years ago with, say, 5-6 devs who would have dealt with it.
With the absolutely rarest exceptions all patch releases are done in the same manner as the regular ones, i.e. from the HEAD of master. History must be as linear, as possible.
So there are basically 2 general cases when you really need to share a commit. In the first, you find out in your branch there's something to be fixed, which you know I already fixed in mine, in the commit X. In this case it's better if I reorder commits in my branch so that X is the first one, create a new branch with X, which then is merged in a proper manner. You can rebase then.
Second case is when 2 people with different skill-sets or responsibilities must work on something that "from the above" looks like the same piece of functionality. Then, however hard you may try, it all turns up much messier and they will end up needing to share branches (so they cannot rebase them) with multiple commits. In this case I name one of them responsible for changes made within this task as a whole, so when the work is finished the second (3rd, 4th,...) person doesn't touch the branch(es) in question any more, and the first one might rebase and clean up it as needed.
More like most times when people look at logs they will only have the first line visible anyway.
Yes, however, -m does encourage people to make single line messages.
The character limits are a real thing in git culture. One could start here, with a question posed by an apparent skeptic:
https://stackoverflow.com/questions/2290016/git-commit-messa...
git log would definitely show the entire commit message, so I don't see why there would be almost no audience. git blame along with git show or git log -n1 would also allow you to see the rest of the commit message for a particular line in the codebase.
git log could show the entire commit message, but I can't remember the last time I saw any developer whose default format wasn't a single-line one. Presumably there are some people who do prefer to see the whole message every time, and maybe that includes you, but IME that's quite rare.
By default, it shows the entire message, and, in my experience, most people aren't going to change the default behavior in one specific case.
That is true, but I literally can't think of any developer I've worked with in many years who had not done something like that. The typical display in every GUI for git repos that I've come across in recent times is also geared to single-line display, though some of them are marginally better with at least indicating the presence of additional lines than git's own one-line display formats in the CLI.
YMMV, and apparently it does, based on your second paragraph.
That's a subjective preference. Maybe for some repos it's a good idea to allow or even require longer messages, but certainly not all.
For example, after seeing many different strategies for commit messages over the years, my own preference in many cases is now to permit only one-line commit messages, with a strict character limit, which include a reference to a suitable source such as a feature or bug ID where more details may be found. With git, this can be checked using a pre-commit hook.
The big advantage of this is that a `git log` or similar command with a single-line format can never then hide anything important. Assuming we're talking about an established project that does have things like a bug tracker and some sort of structured project documentation set up, I have found that any time I am tempted to write a longer commit message, there is usually a better place I could record that information, and if not then maybe it wasn't that important anyway.
YMMV, of course. As I said, it's a subjective preference, and no doubt there are many different ways a team might choose to use their tools.
But why so offensively?
He raised good concerns
That said, that merge log is fairly useless. Whether it needs to be anything other than that, and who generally would see it and whether it's for the person writing it or someone else is something to be discussed, but even in the case it's mainly meant for the author to look back on, is it even succeeding in being useful in that job? I would agree that it appears pathetic, but probably pathetic in a low-cost doesn't really matter way.