After seeing people use the @jetbrains UI to commit to git I understand where all those - sorry: shitty - commit messages come from…

🙈

An improvement would already be to have a “Subject” line and the text box.

And have the subject line follow the Beams Rule.

Sonthat the first line of the commit message finishes the sentence

“When this commit is applied it will…”

And please: No longer than 56(?) characters (Unicode). Keep it short. You got the textbox to explain *why* in full length.

  • Alerta! Alerta!@phpc.socialOP
    link
    fedilink
    arrow-up
    2
    ·
    26 days ago

    @BatmanAoD Because they serve a different purpose.

    Purely semantically a changelog is something different than a git log (otherwise it would be named a git log).

    The changelog is more a log of merges that describes the main overview of new features and also bug fixes.

    If I want to know the exact details why this line of code changed, *then* I look at the git log.

    Having all atomic commitlogs in the changelog tells the user that you are too busy fixing code to give them a meaningful summary

    • Alerta! Alerta!@phpc.socialOP
      link
      fedilink
      arrow-up
      3
      ·
      26 days ago

      @BatmanAoD Besides that a git log and a changelog have different target audiences.

      The gitlog is intended for contributors of the project whereas the chamgelog is intended for users of the project.

      And it helps the users if they get a summarized version of what changed for them.without having to.go.theough each commit amd decide for themselves whether and how that internal change affects the exteenal API and then their usage of it.

      • BatmanAoD@programming.dev
        link
        fedilink
        arrow-up
        1
        arrow-down
        1
        ·
        26 days ago

        The gitlog is intended for contributors of the project whereas the chamgelog is intended for users of the project.

        That makes sense to me.

        I think I would still argue, however, that for projects using github, gitlab, or any similar forge with a built-in pull-request + code-review feature, there’s very limited value in spending time crafting good commit messages in a feature branch. All information that you may be tempted to put there would be more visible and more useful either as code comments (which applies to all projects, not just GH) or as comments in the PR description or discussion. (I also think it’s often better to just squash feature branches on merge than to try to maintain a clean branch history while the feature is in development.)

        I do think that the commit messages that actually end up on your trunk are important; but, with the exception of the final PR merge (or squash) commit, developers should minimize the time spent writing or thinking about these commit messages.

        The one context in which I find details in historical commit messages potentially useful is when using git log -p to figure out when and why something changed. But even then, once I’ve found the relevant commit, looking up the PR to see if there was any discussion about the change in question is generally the next step; so again, having substantial detail in the commit message itself is unlikely to be helpful.

        • Alerta! Alerta!@phpc.socialOP
          link
          fedilink
          arrow-up
          2
          ·
          26 days ago

          @BatmanAoD Having done code archeology for over a decade now I can assure you that the issue with all the information that you need to understand why something was done has been discarded just shortly before due to moving to a different platform… Or something similar.

          In any case: Having all the relevant data in one place and not scattered is a huge advantage.

          • Alerta! Alerta!@phpc.socialOP
            link
            fedilink
            arrow-up
            2
            ·
            26 days ago

            @BatmanAoD And every developer should take the time to create a meaningful commit-message for the work they did. After all they invested a good amount of time into the code change, so why not proudly explain why they did it, what the challenges where and why they did it
            *that* way?

            But on the other hand: It’s documentation, so just drop it 🙈

            Also: Code-comments are fine but tend to rot during code changes. The commit message is always tied to the commit.

            • BatmanAoD@programming.dev
              link
              fedilink
              arrow-up
              1
              arrow-down
              1
              ·
              edit-2
              26 days ago

              It’s not documentation, though. That’s my point. It’s a byproduct of the development cycle, not a place to store important information.

              Commit messages are tied to a commit, sure, but why do you expect developers to have better discipline in writing commit messages than they have in updating code comments?

              • Alerta! Alerta!@phpc.socialOP
                link
                fedilink
                arrow-up
                1
                ·
                26 days ago

                @BatmanAoD Because the commit message is a requirement when committing code. The code comment is sitting there and no one cares whether it’S updated.

                And a certain schema of a commit message can be enforced. Git hooks for example can be used to make sure that the commit message looks a certain way, has a minimum length, is formatted according to declared standards. As one would do for code-style.

                Then they still can just add garbage. But then you have a people problem that no tech will solve

                • Alerta! Alerta!@phpc.socialOP
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  26 days ago

                  @BatmanAoD And the commit message *is* documentation. It explains the “Why” making transparent why the code was written the way it is. If the commit message doesn’T reflect that, then you can also use git commit -m "Fixed issues"

                  But again: That is then a people problem that no tech will solve!

                  • BatmanAoD@programming.dev
                    link
                    fedilink
                    arrow-up
                    2
                    ·
                    26 days ago

                    My point is that “the comments aren’t accurate” is also a people problem. And I absolutely disagree that commit messages are “documentation” of anything except the development history.

          • BatmanAoD@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            26 days ago

            I mean, I’ve been doing this for over a decade too. If teams are losing data from their issue tracker or source forge, that’s a deep problem and not something that can be ameliorated by writing better commit messages.