4 ms·

I have worked on several codebases where it was enforced that the commit be rebased off of whatever the main branch was, all units of work squashed to a single

by rpcope1 9mo ago

I have worked on several codebases where it was enforced that the commit be rebased off of whatever the main branch was, all units of work squashed to a single commit, and only "working" code be checked into the main branch. This gives you a really good linear history, and when you're disciplined about writing good final commit messages and tagging them to a ticket, it means bisecting to find challenging bugs later becomes tractable, as each commit nominally should work and should be ready to deploy for testing. I've personally solved a number of challenging regressions this way.

drysine 9mo ago
>each commit nominally should work Except it can be the result of 10 squashed commits.
- bastardoperator 9mo ago
  Which is the entire point of it. Why should I look at ten commits when I can look at one and get the same exact data? Why should I pollute my production history for what a is likely a bunch of debugging commits? The branch is a scratchpad, you should feel empowered within your own branch, rebase allows you to be lazy in the development cycle while presenting a nice clean set of changes at the end of it.
  - bonzini 9mo ago
    You can split your work in multiple commits and at the same time drop/squash debugging or wip changes. The result allows you to go into much better detail than a PR description.
  - shawndumas 9mo ago
    Yes! When you are deep in the code, your brain operates in a non-linear way. You try a solution, it breaks a test. You patch the test. You realize the variable name is wrong. You fix a typo. Without Squash, the main branch history becomes a timeline of your mental struggle. With Squash, the main branch becomes a catalog of features delivered. No body needs to take a trip on the struggle bus with me...
  - drysine 9mo ago
    >Why should I look at ten commits when I can look at one and get the same exact data? For the same reason you have your production history instead of zip file with code) >while presenting a nice clean set of changes at the end of it The set, yes, not a single squashed commit. >The branch is a scratchpad, you should feel empowered within your own branch, rebase Yes, amend, fixup, rebase. Make it a nice set of small commits.
- Yeroc 9mo ago
  Most of those 10 squashed commits likely had commit comments like: "Cleanup based on PR feedback." etc.
  - drysine 9mo ago
    That's what --amend and --fixup are for.
    - cmrdporcupine 9mo ago
      Which wreaks havoc with githubs shitty code review tool. Which is an argument against GitHub, not clean commit history
      - cluckindan 9mo ago
        Yep. Rebase rewrites history and all the PR review comments vanish.
        drysine 9mo ago
        Gitlab seems fine with it
cryptonector 9mo ago
I think one should be allowed to push commits that don't build or pass tests provided a) they are marked as such (so you can skip them sooner when bisecting) and b) the HEAD commit after each push does build and pass tests.

by rpcope1 9mo ago

drysine 9mo ago

>each commit nominally should work Except it can be the result of 10 squashed commits.

bastardoperator 9mo ago
Which is the entire point of it. Why should I look at ten commits when I can look at one and get the same exact data? Why should I pollute my production history for what a is likely a bunch of debugging commits? The branch is a scratchpad, you should feel empowered within your own branch, rebase allows you to be lazy in the development cycle while presenting a nice clean set of changes at the end of it.
- bonzini 9mo ago
  You can split your work in multiple commits and at the same time drop/squash debugging or wip changes. The result allows you to go into much better detail than a PR description.
- shawndumas 9mo ago
  Yes! When you are deep in the code, your brain operates in a non-linear way. You try a solution, it breaks a test. You patch the test. You realize the variable name is wrong. You fix a typo. Without Squash, the main branch history becomes a timeline of your mental struggle. With Squash, the main branch becomes a catalog of features delivered. No body needs to take a trip on the struggle bus with me...
- drysine 9mo ago
  >Why should I look at ten commits when I can look at one and get the same exact data? For the same reason you have your production history instead of zip file with code) >while presenting a nice clean set of changes at the end of it The set, yes, not a single squashed commit. >The branch is a scratchpad, you should feel empowered within your own branch, rebase Yes, amend, fixup, rebase. Make it a nice set of small commits.
Yeroc 9mo ago
Most of those 10 squashed commits likely had commit comments like: "Cleanup based on PR feedback." etc.
- drysine 9mo ago
  That's what --amend and --fixup are for.
  - cmrdporcupine 9mo ago
    Which wreaks havoc with githubs shitty code review tool. Which is an argument against GitHub, not clean commit history
    - cluckindan 9mo ago
      Yep. Rebase rewrites history and all the PR review comments vanish.
      - drysine 9mo ago
        Gitlab seems fine with it

cryptonector 9mo ago

I think one should be allowed to push commits that don't build or pass tests provided a) they are marked as such (so you can skip them sooner when bisecting) and b) the HEAD commit after each push does build and pass tests.