3 ms·

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

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?
  - secondcoming 6y ago
    People actually allow this!?
    - justinclift 6y ago
      It's a standard practise: 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.
      - mgkimsal 6y ago
        I'm on a project and it's the opposite. Full releases every... 2 months give or take, but every... week or two, there's a round up of 'critical' issues, and you're expected to take just those issues from 'develop' (or somewhere) and get them over in to a 'release' branch of the current released code. I now tend to keep local branches of anything I worked on for months, because 4-6 weeks after it was approved/merged (and deleted) in to 'develop', I may have to also do a 'hot patch' on to a release branch, and cherry picking is the proscribed way of doing it.
        justinclift 6y ago
        That sounds fairly disorganised and nightmare-ish. In practise though, does it work well?
        mgkimsal 6y ago

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?
- secondcoming 6y ago
  People actually allow this!?
  - justinclift 6y ago
    It's a standard practise: 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.
    - mgkimsal 6y ago
      I'm on a project and it's the opposite. Full releases every... 2 months give or take, but every... week or two, there's a round up of 'critical' issues, and you're expected to take just those issues from 'develop' (or somewhere) and get them over in to a 'release' branch of the current released code. I now tend to keep local branches of anything I worked on for months, because 4-6 weeks after it was approved/merged (and deleted) in to 'develop', I may have to also do a 'hot patch' on to a release branch, and cherry picking is the proscribed way of doing it.
      - justinclift 6y ago
        That sounds fairly disorganised and nightmare-ish. In practise though, does it work well?
        mgkimsal 6y ago