3 ms·

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 l

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.

deleted 6y ago
[deleted]
krick 6y ago
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.
- bonzini 6y ago
  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/linux.git/commit/?id=039aeb9deb9291f3b19c375a8bc6fa7f768996cc https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin....
- barrkel 6y ago
  Commits aren't the valuable output of the development process.
  - kevin_thibedeau 6y ago
    They're valuable when you're looking for who broke the codebase.
    - coldtea 6y ago
      You can tell that by the author metadata.
      - paledot 6y ago
        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).
  - u801e 6y ago
    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.
aesyondu 6y ago
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

deleted 6y ago

[deleted]

krick 6y ago

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.

bonzini 6y ago
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/linux.git/commit/?id=039aeb9deb9291f3b19c375a8bc6fa7f768996cc https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin....
barrkel 6y ago
Commits aren't the valuable output of the development process.
- kevin_thibedeau 6y ago
  They're valuable when you're looking for who broke the codebase.
  - coldtea 6y ago
    You can tell that by the author metadata.
    - paledot 6y ago
      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).
- u801e 6y ago
  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.

aesyondu 6y ago

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