Comment by bonzini | Hacker News Reader

Comment by bonzini | Hacker News Reader

Parent Full thread

This is a condensed summary of merges, not the commit messages. The actual commit messages for those merges were:

* A few little subsystems and a start of a lot of MM patches. Subsystems affected by this patch series: squashfs, ocfs2, parisc, vfs. With mm subsystems: slab-generic, slub, debug, pagecache, gup, swap, memcg, pagemap, memory-failure, vmalloc, kasan"

* More mm/ work, plenty more to come. Subsystems affected by this patch series: slub, memcg, gup, kasan, pagealloc, hugetlb, vmscan, tools, mempolicy, memblock, hugetlbfs, thp, mmap, kconfig

* More MM work. 100ish more to go. Mike Rapoport's "mm: remove __ARCH_HAS_5LEVEL_HACK" series should fix the current ppc issue. Various other little subsystems"

* Various trees. Mainly those parts of MM whose linux-next dependents are now merged. I'm still sitting on ~160 patches which await merges from -next. Subsystems affected by this patch series: mm/proc, ipc, dynamic-debug, panic, lib, sysctl, mm/gup, mm/pagemap"

* a kernel-wide sweep of show_stack(); pagetable cleanups; abstract out accesses to mmap_sem - prep for mmap_sem scalability work; hch's user acess work. Subsystems affected by this patch series: debug, mm/pagemap, mm/maccess, mm/documentation.

* various hotfixes and minor things; hch's use_mm/unuse_mm clearnups. Subsystems affected by this patch series: mm/hugetlb, scripts, kcov, lib, nilfs, checkpatch, lib, mm/debug, ocfs2, lib, misc.

* A few fixes and stragglers. Subsystems affected by this patch series: mm/memory-failure, ocfs2, lib/lzo, misc

And of course there are hundreds of commit messages for the patches that describe what is really going on. That said, Andrew Morton works in a different way than every other maintainer so the merge commit messages in his case tend to be much less descriptive than everyone else's.

This is why I hate merge commits. I mean, I have no idea of what constitutes this Morton's work and if he could've done better, but I think messages like that are still a problem, they provide zero value and mess up the log. And this is actually only a little worse than what I usually see in merge commits, especially when they are done with some semi-automated tool like GitLab. People rarely do merge by rebase, all useful things that could've been said are usually in the commits themselves (and there are some guidelines about them), so merge commit messages are rarely empty and even more rarely are they useful, because author has no idea what to say. This is just trash.

And even though it never ocured to me to check, yeah, I'd actually expect a higher quality standards of Linux kernel.

Most merge commits in Linux are all but empty and all but useless. Here is one of mine: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin....

Commits aren't the valuable output of the development process.

They're valuable when you're looking for who broke the codebase.

You can tell that by the author metadata.

They're valuable for when you're looking for why they broke the code base. This looks like dead code, will I break anything if I remove it? Git blame gets me the ticket number, details on the particular change being made, and (if the author writes their commits well) related files and tests associated with this change. From there, I can see if the other code has since been removed, or if there's an edge case I didn't think of, or if the thing was never plugged in in the first place, or if this is a bug no one has noticed. All within two minutes, and without needing to ask the author (if they're even still available).

Using git blame and looking at a commit that last updated a line allows one to check the message for the reasoning behind adding or updating that line, and the context that line was added or updated.

This could help in terms of preventing regressions by making further updates for example.

At least for me, they definitely are one of the valuable outputs of the development process.

Especially when looking back through older code to see "what did we change since X date?", and/or "what changed between (say) the 3rd and 5th of July?".

That seems to be a fairly standard thing too (from my perspective).

You wouldn't be offended, if you possessed the requisite context for your opinions.

Linux kernel commits are very detailed and high quality. The style can be a bit ad hoc, but the face of enforcement is Linus himself.

What you're looking at here is a throwaway piece of unnecessary text. Git offers the opportunity to include it, but it is generally left blank, because it adds no value. All of the interesting bits are included by incorporation.

In this case, Andrew Morton decided to have a bit of ironic fun with the throwaway text. Dismissals ensue!

I'm not really "offended" since I don't really care about the state of Linux kernel's log. But since you insist on the discussing the case so much, let me add that I'm a person with very low tolerance for humour in the working process. I like jokes in the chat, email, or even in bugtracker's comments for that matter, but the git log (or any change log, for that matter) must be very clean, clear and boring.

So even though I said

> I have no idea of what constitutes this Morton's work and if he could've done better

I very much believe that he could have. For 2 reasons:

1. There are multiple people with huge, broad, non-specific merges in that list, and every single one of them, did, in fact do better than Andrew Morton.

2. I believe that consistency in logs is good, so even in the case somebody really, truly, actually cannot say more, than just "updates" about the changes he introduces (which I don't think is ever true, but let's assume it is), I think "updates|updates|updates|updates" would still be a mile better, than "updates|more updates|yet more updates|still more updates".

> it is generally left blank

Not at all.

> it adds no value

It is used by Linus to check what's going on and see if there's anything he should check more closely (perhaps cross-checking the message with the diffstat); it is used by developers (now or in the future) and journalists to make themselves an idea of what is being merged; it may explain features that are in development and have preparatory work being merged; and so on.

So I'd say there's quite a bit of value there.

Every single one of those pieces of information is included in the original commit messages, which are included by incorporation.

The merge commit message is the equivalent of forwarding an email to someone and adding your comment at the top:

    "Really interesting, read this!"

    "Hey, look what Joe said..."

Or the ever-popular message in CEO-speak:

"?"

Rephrasing the committer's message in the merge commit would be redundant at best, and confusing at worst.

Merge/branch commits can’t be useful by definition. No work was done on the branch/merge. I don’t understand your gripe.

Then why are they wasting space in the log? That's the gripe, the white noise.

Because the second parent commit of the merge commit gives you the pointer to the list of commits off the main branch where the feature is implemented. Without the merge commit, there would be no easy way to group commits that implement a feature.

You're focusing on the wrong part of the picture. Yes, you need that data to be stored somewhere. But the complaint is not that a merge commit or equivalent data structure exists somewhere. It's that if you get the equivalent of 'asdflklf' shown in the log, especially when it's displayed in a compact and supposedly information-dense form, something has gone wrong.

If we take it as true that merge commits have no useful information by definition, shouldn't they have a blank commit message? Or a message of "merged branch X"? And why are we spending lines displaying them in the denser log formats?

All of my merge commits say “merged x with y” and all of my branch commits say “created branch z”

They are useful because it shows very clearly when a branch and merge was done. Dates and times are useful. Knowing the parent of a branch is useful. Knowing when a branch was merged back in to another branch is useful.

> It's that if you get the equivalent of 'asdflklf' shown in the log

I think the fundamental problem is that commands like merge and revert generate their own default commit message and don't bring up the editor so that further updates can be made.

At my job, I always will tell people that they need to include why they're reverting a commit in the commit message. I haven't really done anything about enforcing standards on merge commit messages, but perhaps including the cover letter or PR description in the merge commit would be a good start.

I'm not sure what the fuss is all about. I've only been developing for < 2 years, and I used to add detailed MERGE commit messages, but I realized that it's just duplication of information (which can be read from the INDIVIDUAL commit messages). I've left MERGE commit messages empty since then

Reply on news.ycombinator.com