5 ms·

These 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 ago
  Because they are good commits.
- markdown 6y ago
  > pathetic
- mrspeaker 6y ago
  He 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 ago
    This 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 ago
    I'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 ago
I 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 ago
  You 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 ago
    Why can't the same requirement be achieved using meaningful merge messages? I personally usem them.
- krick 6y ago
  I 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 ago
    Have 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 ago
I have worked places that had really good commit messages.
0x00000000 6y ago
Git 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 ago
  agreed... I use -m out of laziness a lot, but every time I don't it's much better.
  - _ikke_ 6y ago
    Note 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 ago
    There 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 ago
  Just 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 ago
  I 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...

tester756 6y ago

>you would ever find in your company VCS. But why so offensively? He raised good concerns

saagarjha 6y ago
Because they are good commits.
markdown 6y ago
> pathetic
mrspeaker 6y ago
He 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 ago
  This 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 ago
  I'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 ago

I 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 ago
You 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 ago
  Why can't the same requirement be achieved using meaningful merge messages? I personally usem them.
krick 6y ago
I 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 ago
  Have 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 ago

I have worked places that had really good commit messages.

0x00000000 6y ago

Git 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 ago
agreed... I use -m out of laziness a lot, but every time I don't it's much better.
- _ikke_ 6y ago
  Note 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 ago
  There 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 ago
Just 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 ago
I 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...