• Eager Eagle@lemmy.worldEnglish
    51·
    5 个月前

    If you write commit messages like this, at least have the decency of squashing them when merging. Thanks.

      • Shanmugha@lemmy.world
        5·
        5 个月前

        Why not get them fired? Call me cruel anyone who feels like it, but leaving no sign of what has been done is just plain shit attitude to colleagues

      • balsoft@lemmy.ml
        2·
        5 个月前

        Maybe you should write a script that spits out AI description for a commit and then run it for commits without a proper description? Since it doesn’t require any insight from the commit author it should work the same.

        • Ephera@lemmy.mlEnglish
          3·
          5 个月前

          Can we at least mention, though, that that’s kind of nonsensical, too? Give me a *very* high-level summary of what changed, but then the rest of the commit message should be the why (unless that’s genuinely obvious, like when adding a feature).

          If I actually want to know what changed, I can look at the code changes. I can’t find the why anywhere else, though. Nor can an LLM having to describe those random code changes.

        • Whelks_chance@lemmy.world
          1·
          5 个月前

          I’m now tempted to do this for all several thousand commits in the main branch, and at the very least create a better changelog.

    • GreenKnight23@lemmy.world
      2·
      5 个月前

      this is literally the only thing I think is acceptable for AI to do for developers.

      nobody reads commit history anyway and they always go straight to blame to find out who to kick the fuck out of.

      • lad@programming.devEnglish
        1·
        5 个月前

        And the blame has those commit messages. That is beside the fact that most authors may not even work there anymore

        • GreenKnight23@lemmy.world
          5·
          5 个月前

          I don’t even waste my time anymore frankly. people just do a git add . and git commit -m "did some stuff".

          sorry, I’ve just worked with a lot of shitbag devs that honestly think of git as a flat filesystem that can’t even properly branch or merge.

          personally, I still put in clear commits and even do patch level adds. from what I have experienced though, using AI to generate those commit messages based on actual changes would be a godsend compared to the fuckery I’ve had to deal with.

          • lad@programming.devEnglish
            3·
            5 个月前

            To this I completely agree, a lot of people don’t want to use the tools for the benefit of the future colleagues or even self

  • Redkey@programming.dev
    20·
    5 个月前

    At the very least, please state which section you made small changes to, even if you are sure it’s not worth mentioning what or why.

    • merc@sh.itjust.works
      2·
      5 个月前

      Also, what were you hoping to accomplish? At a minimum, are you fixing a bug? Adding a feature? Cleaning up ugly code? Trying to improve performance? Adding comments to something that wasn’t obvious?

      Did you change an interface that other people use in a way that might break something? Even if it’s fixing a bug, is that a bug that other people might have been relying on?

      I think the most problematic changes are the little fixes, because often the CL goes from something that looks like it should work, to something else that also looks like it should work. It’s very helpful when the commit message describes how it was broken. Otherwise, if you have to roll back the changes you don’t know what might get broken again.

  • GissaMittJobb@lemmy.ml
    20·
    5 个月前

    Curate your commits, friends. They should be structured for the benefit of the reviewer. This can be accomplished with liberal use of interactive rebasing.

  • NocturnalMorning@lemmy.world
    9·
    5 个月前

    I once found a commit message in our commit history that just said, “i hate git…” bcz they hadn’t changed anything, and I think it took a new line character and decided that they’d actually changed like 5 lines of code twhen they hadn’t.

    It was the funniest shit, someone who was a senior lead for like 9 years that had left, and 5 years later I find that…

  • MonkderVierte@lemmy.zipBanned
    8·
    5 个月前

    git commit -m “A spirit trapped within a tree, no mouth to scream or eyes to see. A cage of bark, a prison of wood. A thing of rage where nature stood.”

    • merc@sh.itjust.works
      2·
      5 个月前

      See also semantic commit messages where you tag every commit with the type of commit: feature, fix, docs, refactor, test, etc.

      My only beef with it is that they chose “feat” as a way to shorten the word “feature” when “feat” is already a word that means something different. Not every feature is a feat, and a lot of the biggest feats are actually bug fixes.

      • PastelKeystone@lemmy.worldEnglish
        1·
        5 个月前

        I’ve seen semantic commits done with emojis which is cute but also annoying, because they’re not as easy to type or grep for.

        Semantic commits can be nice, but they can also invite bikeshedding about what’s a “feature” and what’s a “bug fix”, etc.

        Not saying they aren’t nice, and if folks are using them and liking them, keep going. But if you haven’t used them before on a team, then just be aware that’s a thing than can happen.

        • merc@sh.itjust.works
          1·
          5 个月前

          I’d rather have bikeshedding over terminology that eventually results in a single word than just have free-form commits where you can never tell what the primary motivation between a commit is.

  • MTK@lemmy.world
    2·
    5 个月前

    For complex changes go with “self-explanatory” just to fuck with peoples’ confidence

  • jjjalljs@ttrpg.network
    2·
    5 个月前

    I’ve worked with a few people who are just incomprehensible. One refuses to write commit messages of any detail. Just “work in progress”. Cast him into the pit.

    There was another guy that refused to name his tests. His code was like

    describe(''. () => {
  it('', () => {
     expect(someFunc()).toEqual(0);
  }
 it('', () => {
    expect(someFunc(1)).toEqual(0);
  }
 it('', () => {
   expect(someFunc("").toEqual(1);
 }
}

    He was like, “Test names are like comments and they turn into lies! So I’m not going to do it.”

    I was like, a. what the fuck. b. do you also not name your files? projects? children?

    He was working at a very big company last I heard.

    edit: If you’re unfamiliar, the convention is to put a human readable description where those empty strings are. This is used in the test output. If one fails, it’ll typically tell include the name in the output.

    • merc@sh.itjust.works
      1·
      5 个月前

      I get the hesitation that things can turn into lies, but that’s a sign that you’re doing things wrong. That also tends to happen to comments that are far away from the relevant code, like the documentation of a 100 line function. The function can change while the comment is no longer visible on the screen, so it’s easy to forget to also fix the comment.

      But test strings like that are designed to avoid that problem. They’re right there next to your tests for a reason. You should always be right next to them when you’re changing the test.

      Fundamentally, this is something that has to be addressed with code reviews. If someone can commit their changes to a group repository without anybody else seeing them, you’re going to get stuff like this. As soon as you get decent code reviews, you can just reject a change where there are tests without documentation, the same way you can reject a change to a test where the documentation is now out of date.

      • jjjalljs@ttrpg.network
        2·
        5 个月前

        Code reviews are important. Unfortunately, no-test-text guy convinced his whole team that he was right, and I wasn’t able to block it. I’d scheduled a meeting to try to get the wider org to adopt a more sensible standard, but then there was a mass layoff 🤷

        The other guy with the bad messages is at a tiny startup where they’ve laid off almost everyone, and the other 2 guys don’t want to make waves. The CEO is big on “just ship it” (and also “why are there bugs in production? this is unacceptable!!”)