7 ms·
Andrew Morton (7): updates more updates yet more updates still more updates even more updates some more updates updates Real illumi
by spanhandler 6y ago
Andrew Morton (7):
updates
more updates
yet more updates
still more updates
even more updates
some more updates
updates
Real illuminating merge log there bud :-)
- wmichelin 6y agoI'm surprised this is allowed in the linux kernel. I am not familiar, but assuming these are commit messages, that's pretty damn pathetic.
- stefan_ 6y agoThese are only merges - they don't matter. The actual functional commits are excellent beyond anything you would ever find in your company VCS.
- tester756 6y ago>you would ever find in your company VCS. But why so offensively? He raised good concerns
- saagarjha 6y agoBecause they are good commits.
- markdown 6y ago> pathetic
- mrspeaker 6y agoHe didn't raise good concerns, he got outraged after reading a HN comment and labeled "pathetic" something he knows nothing about, has no context in, and didn't even spend 5 minutes researching.
- sushshshsh 6y agoThis is the correct answer. The difference between the messages I leave for myself in my local merges and my actual commits to the dev branch are night and day.
- kbenson 6y agoI'm not sure I'd classify what I read as "outraged" (different people express themselves in different ways, not everyone uses "pathetic" with the same vehemence or vitriol). 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.
- MayeulC 6y agoI still wish people would give meaningful names to their merge commits. Together with `git log --first-parent` and the alligator [1] workflow, it can filter out the less interesting patch series to focus on the bigger picture (the fact that you added a functionality, not that it took you 53 commits changing very specific parts to do so). [1]: https://euroquis.nl/blabla/2019/08/09/git-alligator.html https://euroquis.nl/blabla/2019/08/09/git-alligator.html
- stefan_ 6y agoYou are looking for the cover letter, a random example: https://patchwork.freedesktop.org/series/73884/ https://patchwork.freedesktop.org/series/73884/ With the current kernel development model these aren't recorded in the actual tree, though.
- feanaro 6y agoWhy can't the same requirement be achieved using meaningful merge messages? I personally usem them.
- krick 6y agoI agree, I don't think "it's only a merge commit" is any excuse whatsoever. But I personally pretty aggressively squash my commits with "rebase -i" before merge, exactly in order for there to be not much of a "bigger picture". And I urge others to do the same as well, because no matter how many fixes there was during the development, later on everybody will ultimately care only about "what it was about in the essence?" I.e., added functionality this-and-that, or a fix, or refactoring, or maybe something new implemented (but not "active" as of yet). Small commits are nice when doing git bisect, but given your code is not a complete trash, it is properly tested and refactoring (which is usually the biggest code change anyway) is separated from the "meaningful" changes, there's no much use in them after a year. So the best use I've seen for the merge commits are bugtracker task IDs and such.
- barrkel 6y agoHave you ever worked in a team context where you needed to share a cherry picked commit between branches? Or e.g. between develop and a patch release?
- cortesoft 6y agoI have worked places that had really good commit messages.
- 0x00000000 6y agoGit and Subversion even allowing single line “-m” commit messages was a mistake. You would see a lot better messages if they forced you to use the editor. I bet a lot of programmers don’t even know you could do multi line messages and assume there is some short-ish character limit. I know I did for a long time
- cozzyd 6y agoagreed... I use -m out of laziness a lot, but every time I don't it's much better.
- _ikke_ 6y agoNote that you can provide -m multiple times to add multiple paragraphs to the commit message.
- worldsayshi 6y ago> lot of programmers don’t even know you could do multi line messages More like most times when people look at logs they will only have the first line visible anyway.
- benibela 6y agoThere are probably programmers that do not know there can be more than one line even after looking at a commit with a multi line message
- jimktrains2 6y agoJust a bit, you can have multiple lines with -m, I do it frequently. You can also write single line messages in an editor, which I'm also frequently guilty of. They're orthogonal issues. Yes, however, -m does encourage people to make single line messages.
- cardiffspaceman 6y agoI feel a huge pain of resignation when I am forced to use multiple lines to describe a single commit. There is almost no audience for any line of the commit message other than the first line. As far as line length goes, any practical means of displaying the messages, like gitk or git --oneline, is unfriendly to lengthy lines. Gerrit will display all the lines of the tip commit's commit message, so one can amend that commit to create a summary of the others, but then of course the other commits are not as visible. 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-messages-50-72-formatting https://stackoverflow.com/questions/2290016/git-commit-messa...
- bonzini 6y agoThis 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 agoThis 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.
- geofft 6y agoThis appears to be Linus's rephrasing/summarizing of the commit messages, not actual commit messages anywhere in git history.
- coldtea 6y ago> I'm surprised this is allowed in the linux kernel. I am not familiar, but assuming these are commit messages, that's pretty damn pathetic. Those are mergers, and besides they care more about quality of the commits, than about the quality of commit messages. It's one of the perks not having some superficial scrum master to satisfy.
- api 6y agoMy commit logs tend to be full of stuff like "now with less bugs" and "it actually works."
- ldiracdelta 6y agoI do too, but I also do not have a sizable fraction of _civilization_ running on top of my code.
- spanhandler 6y agoI do a ton of that locally (or, sometimes, in a remote branch that I 100% own and no-one else will be touching), but clean it up before pushing or merging.
- benibela 6y agoIn academia, nearly all our commit messages are "..." But once the paper is published no one will ever look at the commits again