6 ms·

I have a guy on me team that commits basically every 5 or so lines. Hell have a 30 line bug fix spread across like 20 commits because he never goes back and cl

I have a guy on me team that commits basically every 5 or so lines. Hell have a 30 line bug fix spread across like 20 commits because he never goes back and cleans up those small commits that get changed afterwards, not to mention he’ll merge the development branch into it numerous times and never rebased. It’s absolutely infuriating reading through git logs that involve his stuff. His commit messages are equally maddening - “change this variable to 5”, “fix broken spec”, “change variable to 7” ad nauseam…

WolfeReader 4y ago
You're lucky that you have him.
- rubyist5eva 4y ago
  Not really because none of his commits have any context on what the purpose any of his changes are actually for. He never describes why he does anything, just that he is changing something (which is obvious from the code). It's the git equivalent of "useless comments" like `int x = 10; // set x to 10`
  - FPGAhacker 4y ago
    In my opinion, commits aren't a record of why. They are a record of what. Commit messages a shorthand of what for easier skimming. Comments answer why (and even 'what' is fine if the code is difficult.) But simple rules like that always have exceptions.
SketchySeaBeast 4y ago
Assuming you squash the PR and view it holistically, what's the issue?
- rubyist5eva 4y ago
  PRs dont' squashed, nothing gets rebased and only merge commits are allowed for anything non-local. It adds noise to trying to figure out why changes are made because the commit messages only explain what was changed, not the purpose or context.
  - SketchySeaBeast 4y ago
    If you're not squashing your PR's I can see the problem, but I also see the other problem.
    - maleldil 4y ago
      Do you think squashing the PR is the superior choice? Why?
      - SketchySeaBeast 4y ago
        Because then you don't see all those minor little changes and can view the PR holistically. I don't typically find that viewing the changes in chronologically order buys much, it's not the order I care about, it's the final changes themselves that have an impact on the system, especially when those changes could be transient (changing something in commit #1, change it back in commit #3). There's a larger load to comprehension with a squashed commit, but it shouldn't be THAT large, and it removes all the temporal noise. It also makes tracing the historical "why" of a change easier to understand. If you don't squash it's a random change in the log, if you do squash then it's "adding feature x".
edgyquant 4y ago
This is kind of like me except I list the component, function or class I did the change in. We do a squash on each branch before merging anyway

WolfeReader 4y ago

You're lucky that you have him.

rubyist5eva 4y ago
Not really because none of his commits have any context on what the purpose any of his changes are actually for. He never describes why he does anything, just that he is changing something (which is obvious from the code). It's the git equivalent of "useless comments" like `int x = 10; // set x to 10`
- FPGAhacker 4y ago
  In my opinion, commits aren't a record of why. They are a record of what. Commit messages a shorthand of what for easier skimming. Comments answer why (and even 'what' is fine if the code is difficult.) But simple rules like that always have exceptions.

SketchySeaBeast 4y ago

Assuming you squash the PR and view it holistically, what's the issue?

rubyist5eva 4y ago
PRs dont' squashed, nothing gets rebased and only merge commits are allowed for anything non-local. It adds noise to trying to figure out why changes are made because the commit messages only explain what was changed, not the purpose or context.
- SketchySeaBeast 4y ago
  If you're not squashing your PR's I can see the problem, but I also see the other problem.
  - maleldil 4y ago
    Do you think squashing the PR is the superior choice? Why?
    - SketchySeaBeast 4y ago
      Because then you don't see all those minor little changes and can view the PR holistically. I don't typically find that viewing the changes in chronologically order buys much, it's not the order I care about, it's the final changes themselves that have an impact on the system, especially when those changes could be transient (changing something in commit #1, change it back in commit #3). There's a larger load to comprehension with a squashed commit, but it shouldn't be THAT large, and it removes all the temporal noise. It also makes tracing the historical "why" of a change easier to understand. If you don't squash it's a random change in the log, if you do squash then it's "adding feature x".

edgyquant 4y ago

This is kind of like me except I list the component, function or class I did the change in. We do a squash on each branch before merging anyway