Revisiting David Thompson's "My favourite Git commit"
  • Eager Eagle@lemmy.worldEnglish
    0·
    19 days ago

    I just keep my commit messages one-liners and elaborate more on pull requests, where there’s enough context to really justify the change.

    • zygo_histo_morpheus@programming.dev
      1·
      19 days ago

      Putting the message in git puts the information closer to the code, since the pr isn’t in git itself but instead the git forge. You can for example search the text of git messages from the git cli, or come across the explanation when doing git blame. I sometimes write verbose commit messages and then use them as the basis for the text in the pr, that way the reviewer can see it easily, but it’s also available to anyone who might come across it when doing git archeology

  • CaptainBlagbird@lemmy.world
    0·
    19 days ago

    At work we always put an issue number (together with a short summary text) in the commit message. The the verbose explenation is done in the issue, where formatting, search and filtering is easier. However this creates a dependency to that issue system.

    • Eager Eagle@lemmy.worldEnglish
      1·
      19 days ago

      yeah, trying to convince our product owner to read commit messages wouldn’t go smoothly in my team. Some of them love their tickets…

      the dependency to the issue system is unfortunate though, I do miss a “decentralized issue system” doing what git does for version control that would just seamlessly integrate with git and have a nice web GUI for less technical folks.