3 ms·

Maybe it does, but couldn’t the developer write more descriptively? The argument is a non sequitur too: It does not follow that a git merge strategy that keeps

Maybe it does, but couldn’t the developer write more descriptively? The argument is a non sequitur too: It does not follow that a git merge strategy that keeps all commits is at fault for a culture of writing bad commit messages. Presenting that argument as a rationale for avoiding straight merges while preferring squashing and/or rewriting history is the strawman.

masklinn 4y ago
> Maybe it does, but couldn’t the developer write more descriptively? Commonly while you're fixing things up there's nothing of worth to be descriptive about. "made test x pass" is a useful checkpoint during development, it's not a useful step to conserve forever. > The argument is a non sequitur too: It does not follow that a git merge strategy that keeps all commits is at fault for a culture of writing bad commit messages. I see your accusation of strawmanning was just projection. Thank you for the insight, have a nice day.
- eurasiantiger 4y ago
  ”Made test x pass” is still a bad commit message, as it says nothing about what changes were made to the codebase — which are always made when ”fixing things up”! I did not intend for my comment to be taken as an accusation, as that would imply intention on your part. I simply meant to point out the logical fallacy in statements I read online, i.e. ”because someone on the Internet was wrong”. Trying to gaslight me with personal accusations of psychological projection, however, is crossing a line. Do not do that to other people, it is violence. You do not know what I think or feel, only what I write.
  - metadat 4y ago
    Spending excessive time authoring high quality commit messages for low value commits [during development] is a waste of time. In general it will end up costing you in pure velocity, and reduce how much can get done in a day.
    - seba_dos1 4y ago
      You do know that temporary commits made locally that usually should never leave your development machine are not the ones that you push out to review and merge, right?
      - metadat 4y ago
        "Should" is a funny word. I push funky commits to development branches often, because I always try to sync my work to the git host at the end of the workday in case I wakeup to a non-functioning laptop the next morning. Better to have a risk of ugly commits in a wip branch than risk losing work. > Temporary commits .. are not the ones you push out to review, right? Fully agree with this; I am a clean freak and groom the entire branch differential into sets of atomic or related commits before submitting a merge request.
        eurasiantiger 4y ago
        How often does someone go through your code commit-wise? What is the business value of grooming commits, if the reviewer only looks at the branch diff (as they very well should, lest they miss something in the big picture)?
        seba_dos1 4y ago
        I go through individual commits during review quite regularly. Sometimes it's enough to look at the diff of the whole branch, but sometimes it's much more manageable to look at individual commits for meaningful review.
        u801e 4y ago
        They are valuable when using git blame to see the line in the context of the change it was part of and the associated commit message. That information could help avoid introducing a regression for example.
        seba_dos1 4y ago
        > I push funky commits to development branches often, because I always try to sync my work to the git host at the end of the workday I do that too, and also to get CI artifacts - but I consider that an "implementation detail" that doesn't affect any other part of the development process ;)

masklinn 4y ago

> Maybe it does, but couldn’t the developer write more descriptively? Commonly while you're fixing things up there's nothing of worth to be descriptive about. "made test x pass" is a useful checkpoint during development, it's not a useful step to conserve forever. > The argument is a non sequitur too: It does not follow that a git merge strategy that keeps all commits is at fault for a culture of writing bad commit messages. I see your accusation of strawmanning was just projection. Thank you for the insight, have a nice day.

eurasiantiger 4y ago
”Made test x pass” is still a bad commit message, as it says nothing about what changes were made to the codebase — which are always made when ”fixing things up”! I did not intend for my comment to be taken as an accusation, as that would imply intention on your part. I simply meant to point out the logical fallacy in statements I read online, i.e. ”because someone on the Internet was wrong”. Trying to gaslight me with personal accusations of psychological projection, however, is crossing a line. Do not do that to other people, it is violence. You do not know what I think or feel, only what I write.
- metadat 4y ago
  Spending excessive time authoring high quality commit messages for low value commits [during development] is a waste of time. In general it will end up costing you in pure velocity, and reduce how much can get done in a day.
  - seba_dos1 4y ago
    You do know that temporary commits made locally that usually should never leave your development machine are not the ones that you push out to review and merge, right?
    - metadat 4y ago
      "Should" is a funny word. I push funky commits to development branches often, because I always try to sync my work to the git host at the end of the workday in case I wakeup to a non-functioning laptop the next morning. Better to have a risk of ugly commits in a wip branch than risk losing work. > Temporary commits .. are not the ones you push out to review, right? Fully agree with this; I am a clean freak and groom the entire branch differential into sets of atomic or related commits before submitting a merge request.
      - eurasiantiger 4y ago
        How often does someone go through your code commit-wise? What is the business value of grooming commits, if the reviewer only looks at the branch diff (as they very well should, lest they miss something in the big picture)?
        seba_dos1 4y ago
        I go through individual commits during review quite regularly. Sometimes it's enough to look at the diff of the whole branch, but sometimes it's much more manageable to look at individual commits for meaningful review.
        u801e 4y ago
        They are valuable when using git blame to see the line in the context of the change it was part of and the associated commit message. That information could help avoid introducing a regression for example.
      - seba_dos1 4y ago
        > I push funky commits to development branches often, because I always try to sync my work to the git host at the end of the workday I do that too, and also to get CI artifacts - but I consider that an "implementation detail" that doesn't affect any other part of the development process ;)