5 ms·

> If you squash on merge, you’re doing it wrong. If you’ve never used git blame, you’re doing it wrong. If your repo’s history is useless, you’re doing it wrong

> If you squash on merge, you’re doing it wrong. If you’ve never used git blame, you’re doing it wrong. If your repo’s history is useless, you’re doing it wrong. If you didn’t add a typo fix or white line change as a separate commit, you’re doing it wrong. I agree Git Blame is useful, but squash on merge is great, and having atomic commits for whiteline changes is overkill. Looking forward to that fleshed out blog post on git

SoftTalker 3y ago
[dead]
ajkjk 3y ago
Yeah, I'd say "if you use merge you're doing it wrong". Rebase + squash everything is the only way to go unless you're merging a giant feature branch in... and even then, try to avoid that.
- GolDDranks 3y ago
  I'd say that git rebase -i + squashing selectively is my favorite. I generally strive to make each commit into a meaningful set of changes than I can explain one-by-one, but if they are too big, it's harder to review.
- CuriousCosmic 3y ago
  I'd staunchly disagree. Merges make sense when you develop with the patchset git style. i.e. 1. Write a bunch of code and just scratch it out, stashing in your `FEATURE` branch until the feature is done. 2. Rebase that `FEATURE` branch into sane commits that each accomplish an atomic substep in the implementation of your feature. Each discrete commit/change should build and pass tests. 3. Open your code for review, either via a PR or by submitting the patchset to a mailing list. 4. Implement requested changes as a `FEATURE-v2` (or `FEATURE-vX`) branch. 5. Rebase your `FEATURE-v2`/`FEATURE-vX` branch to clean up your changes and get them to roughly line up with your "final" commits from your previous `FEATURE` branch. 6. Submit your new patchset revision to the mailing list in reply to your last patchset revision. Or if you are using pull requests, change the merging branch from `FEATURE` to `FEATURE-v2`. Then cycle back to step 4-6, rinse repeat until everyone is happy. Then you merge in the final `FEATURE-vX` branch. This leaves you with a history where each individual commit is a useful, descriptive, and fully functional change to the codebase but also with a merge for the full feature at the top. That's important because git tooling actually can iterate over all commits or over only top level commits without traversing into merges. Then it's way easier to identify which feature introduced the issue in question and you can easily peek into the feature's individual commits to understand each discrete change and exactly what the intent was.
  - ajkjk 3y ago
    Definitely disagree. No individual commits should ever exist that aren't safe in prod. Your intermediate commits could be any old state, plus they're not useful in the future. The unit of code landing should be the single commit unless the team as a whole does parallel development in a separate branch for a while.
- lmm 3y ago
  Rebase and squash makes your bisects worse for no real benefit. OP is wrong about commit messages ("fixp" is fine, most of the time you're not going to read the commit message) but right about everything else on the git side.
  - juped 3y ago
    of course no one reads your commit messages if they're useless!
    - lmm 3y ago
      I've worked at places that enforced "good" commit messages. They didn't get read any more, they just meant people committed less often and so commits were less atomic (e.g. people wouldn't bother splitting formatting changes out into a separate commit because they'd have to write another commit message) and bisect was less useful.
      - ajkjk 3y ago
        Good commit messages are about 1s more work than bad ones. They don't have to be long, they just have to say something concrete and useful and instill confidence in the change. If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least). But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction.
        lmm 3y ago
        > If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least). Sure. But the point is to get away from doing those "complicated arduous change"s, and split them up into much smaller pieces. Being able to commit without breaking your flow helps a lot with that. > But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction. This is a purely circular argument. "It's important to have high quality commit messages so that you will have high quality commit messages". It really isn't.
deleted 3y ago
[deleted]
CuriousCosmic 3y ago
>I agree Git Blame is useful, but squash on merge is great, and having atomic commits for whiteline changes is overkill. FWIW this is something you see commonly on mailinglists. Each line you modify in a given commit is assumed to be specifically related to the change described in the commit description. It's just easier for reviewers when you break whitespace changes or non-semantic text changes out into separate commits so that they don't have to try and figure out which lines are semantic changes and which aren't. Given that people who work with patchsets tend to do a lot of rebasing in their workflows, they are generally familiar enough with rebasing to just split out a set of changes from a given commit into two commits in a minute or less.

SoftTalker 3y ago

[dead]

ajkjk 3y ago

Yeah, I'd say "if you use merge you're doing it wrong". Rebase + squash everything is the only way to go unless you're merging a giant feature branch in... and even then, try to avoid that.

GolDDranks 3y ago
I'd say that git rebase -i + squashing selectively is my favorite. I generally strive to make each commit into a meaningful set of changes than I can explain one-by-one, but if they are too big, it's harder to review.
CuriousCosmic 3y ago
I'd staunchly disagree. Merges make sense when you develop with the patchset git style. i.e. 1. Write a bunch of code and just scratch it out, stashing in your `FEATURE` branch until the feature is done. 2. Rebase that `FEATURE` branch into sane commits that each accomplish an atomic substep in the implementation of your feature. Each discrete commit/change should build and pass tests. 3. Open your code for review, either via a PR or by submitting the patchset to a mailing list. 4. Implement requested changes as a `FEATURE-v2` (or `FEATURE-vX`) branch. 5. Rebase your `FEATURE-v2`/`FEATURE-vX` branch to clean up your changes and get them to roughly line up with your "final" commits from your previous `FEATURE` branch. 6. Submit your new patchset revision to the mailing list in reply to your last patchset revision. Or if you are using pull requests, change the merging branch from `FEATURE` to `FEATURE-v2`. Then cycle back to step 4-6, rinse repeat until everyone is happy. Then you merge in the final `FEATURE-vX` branch. This leaves you with a history where each individual commit is a useful, descriptive, and fully functional change to the codebase but also with a merge for the full feature at the top. That's important because git tooling actually can iterate over all commits or over only top level commits without traversing into merges. Then it's way easier to identify which feature introduced the issue in question and you can easily peek into the feature's individual commits to understand each discrete change and exactly what the intent was.
- ajkjk 3y ago
  Definitely disagree. No individual commits should ever exist that aren't safe in prod. Your intermediate commits could be any old state, plus they're not useful in the future. The unit of code landing should be the single commit unless the team as a whole does parallel development in a separate branch for a while.
lmm 3y ago
Rebase and squash makes your bisects worse for no real benefit. OP is wrong about commit messages ("fixp" is fine, most of the time you're not going to read the commit message) but right about everything else on the git side.
- juped 3y ago
  of course no one reads your commit messages if they're useless!
  - lmm 3y ago
    I've worked at places that enforced "good" commit messages. They didn't get read any more, they just meant people committed less often and so commits were less atomic (e.g. people wouldn't bother splitting formatting changes out into a separate commit because they'd have to write another commit message) and bisect was less useful.
    - ajkjk 3y ago
      Good commit messages are about 1s more work than bad ones. They don't have to be long, they just have to say something concrete and useful and instill confidence in the change. If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least). But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction.
      - lmm 3y ago
        > If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least). Sure. But the point is to get away from doing those "complicated arduous change"s, and split them up into much smaller pieces. Being able to commit without breaking your flow helps a lot with that. > But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction. This is a purely circular argument. "It's important to have high quality commit messages so that you will have high quality commit messages". It really isn't.

deleted 3y ago

[deleted]

CuriousCosmic 3y ago

>I agree Git Blame is useful, but squash on merge is great, and having atomic commits for whiteline changes is overkill. FWIW this is something you see commonly on mailinglists. Each line you modify in a given commit is assumed to be specifically related to the change described in the commit description. It's just easier for reviewers when you break whitespace changes or non-semantic text changes out into separate commits so that they don't have to try and figure out which lines are semantic changes and which aren't. Given that people who work with patchsets tend to do a lot of rebasing in their workflows, they are generally familiar enough with rebasing to just split out a set of changes from a given commit into two commits in a minute or less.