3 ms·

I like keeping old branches but a lot of places ditch them, never understood why. I also dislike git squash, it means you have to make a brand new branch for yo

I like keeping old branches but a lot of places ditch them, never understood why. I also dislike git squash, it means you have to make a brand new branch for your next PR, waste of time when I should be able to pull down master / dev / main / whatever and merge it into my working branch. I guess this is another reason I prefer the forking approach of github, let devs have their own sandbox and their own branches, and let them get their work done, they will PR when its ready.

eddd-ddde 10mo ago
I'm very fortunate to not have to use PR style forges at work (branch based, that is). Instead each commit is its own unit of code to review, test, and merge individually. I never touch branches anymore since I also use JJ locally.
- catlifeonmars 10mo ago
  What is JJ?
  - Denvercoder9 10mo ago
    https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj
sallveburrpi 10mo ago
squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess
- Faaak 10mo ago
  What about separate, atomic, commits? Are they squashed too? Makes reverting a fix harder without impacting the rest, no?
  - ezfe 10mo ago
    PRs should be atomic, if they need to be separated for reverting, they should be multiple PRs.
- Denvercoder9 10mo ago
  Squashing only results in a cleaner commit history if you're making a mess of the history on your branches. If you're structuring the commit history on your branches logically, squashing just throws information away.
  - TheGRS 10mo ago
    Not everyone develops and commits the same way and mandating squashing is a much simpler management task than training up everyone to commit in a similar manner.
    - esafak 10mo ago
      Besides, they probably shouldn't make PR commits atomic, but do so as often as needed. It's a good way to avoid losing work. This is in tension with leaving behind clean commits, and squashing resolves it.
      - gbear605 10mo ago
        The solution there is to make your commit history clean by rebasing it. I often end my day with a “partial changes done” commit and then the next day I’ll rebase it into several commits, or merge some of the changes into earlier commits. Even if we squash it into main later, it’s helpful for reviewing.
    - sallveburrpi 10mo ago
      We also do conventional commits: https://www.conventionalcommits.org/ https://www.conventionalcommits.org/ Other than that pretty free how you write commit messages
  - mmh0000 10mo ago
    True but. There's a huge trade-off in time management. I can spend hours OCDing over my git branch commit history. -or- I can spend those hours getting actual work done and squash at the end to clean up the disaster of commits I made along the way so I could easily roll back when needed.
- UltraSane 10mo ago
  "squash results in a cleaner commit history" Isn't the commit history supposed to be the history of actual commits? I have never understood why people put so much effort into falsifying git commit histories.
  - catlifeonmars 10mo ago
    “Falsifying” is complete hyperbole. Git commit history is a tool and not everyone derives the same ROI from the effort of preserving it. Also squashing is pretty effortless.
  - alemanek 10mo ago
    Here is how I think of it. When I am actively developing a feature I commit a lot. I like the granularity at that stage and typically it is for an audience of 1 (me). I push these commits up in my feature branch as a sort of backup. At this stage it is really just whatever works for your process. When I am ready to make my PR I delete my remote feature branch and then squash the commits. I can use all my granular commit comments to write a nice verbose comment for that squashed commit. Rarely I will have more than one commit if a user story was bigger than it should be. Usually this happens when more necessary work is discovered. At this stage each larger squashed commit is a fully complete change. The audience for these commits is everyone who comes after me to look at this code. They aren’t interested in seeing it took me 10 commits to fix a test that only fails in a GitHub action runner. They want the final change with a descriptive commit description. Also if they need to port this change to an earlier release as a hotfix they know there is a single commit to cherry pick to bring in that change. They don’t need to go through that dev commit history to track it all down.
    - UltraSane 10mo ago
      The "cleaner" commit history should be a separate layer and the actual commit history should never be altered.
  - jtafurth 10mo ago
    There are several valid reasons to "falsify" commit history. - You need to remove trash commits that appear when you need to rerun CI. - You need to remove commits with that extra change you forgot. - You want to perform any other kind of rebase to clean up messages. I assume in this thread some people mean squashing from the perspective of a system like Gitlab where it's done automatically, but for me squashing can mean simply running an interactive (or fixup) and leaving only important commits that provide meaningful information to the target branch.
- awesome_dude 10mo ago
  Squash loses the commit history - all you end up with is merge merge merge It's harder to debug as well (this 3000line commit has a change causing the bug... best of luck finding it AND why it was changed that way in the first place. I, myself, prefer that people tidy up their branches such that their commits are clear on intent, and then rebase into main, with a merge commit at the tip (meaning that you can see the commits AND where the PR began/ended. git bisect is a tonne easier when you have that
normie3000 10mo ago
> you have to make a brand new branch for your next PR Is there overhead to creating a branch?

eddd-ddde 10mo ago

I'm very fortunate to not have to use PR style forges at work (branch based, that is). Instead each commit is its own unit of code to review, test, and merge individually. I never touch branches anymore since I also use JJ locally.

catlifeonmars 10mo ago
What is JJ?
- Denvercoder9 10mo ago
  https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj

sallveburrpi 10mo ago

squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess

Faaak 10mo ago
What about separate, atomic, commits? Are they squashed too? Makes reverting a fix harder without impacting the rest, no?
- ezfe 10mo ago
  PRs should be atomic, if they need to be separated for reverting, they should be multiple PRs.
Denvercoder9 10mo ago
Squashing only results in a cleaner commit history if you're making a mess of the history on your branches. If you're structuring the commit history on your branches logically, squashing just throws information away.
- TheGRS 10mo ago
  Not everyone develops and commits the same way and mandating squashing is a much simpler management task than training up everyone to commit in a similar manner.
  - esafak 10mo ago
    Besides, they probably shouldn't make PR commits atomic, but do so as often as needed. It's a good way to avoid losing work. This is in tension with leaving behind clean commits, and squashing resolves it.
    - gbear605 10mo ago
      The solution there is to make your commit history clean by rebasing it. I often end my day with a “partial changes done” commit and then the next day I’ll rebase it into several commits, or merge some of the changes into earlier commits. Even if we squash it into main later, it’s helpful for reviewing.
  - sallveburrpi 10mo ago
    We also do conventional commits: https://www.conventionalcommits.org/ https://www.conventionalcommits.org/ Other than that pretty free how you write commit messages
- mmh0000 10mo ago
  True but. There's a huge trade-off in time management. I can spend hours OCDing over my git branch commit history. -or- I can spend those hours getting actual work done and squash at the end to clean up the disaster of commits I made along the way so I could easily roll back when needed.
UltraSane 10mo ago
"squash results in a cleaner commit history" Isn't the commit history supposed to be the history of actual commits? I have never understood why people put so much effort into falsifying git commit histories.
- catlifeonmars 10mo ago
  “Falsifying” is complete hyperbole. Git commit history is a tool and not everyone derives the same ROI from the effort of preserving it. Also squashing is pretty effortless.
- alemanek 10mo ago
  Here is how I think of it. When I am actively developing a feature I commit a lot. I like the granularity at that stage and typically it is for an audience of 1 (me). I push these commits up in my feature branch as a sort of backup. At this stage it is really just whatever works for your process. When I am ready to make my PR I delete my remote feature branch and then squash the commits. I can use all my granular commit comments to write a nice verbose comment for that squashed commit. Rarely I will have more than one commit if a user story was bigger than it should be. Usually this happens when more necessary work is discovered. At this stage each larger squashed commit is a fully complete change. The audience for these commits is everyone who comes after me to look at this code. They aren’t interested in seeing it took me 10 commits to fix a test that only fails in a GitHub action runner. They want the final change with a descriptive commit description. Also if they need to port this change to an earlier release as a hotfix they know there is a single commit to cherry pick to bring in that change. They don’t need to go through that dev commit history to track it all down.
  - UltraSane 10mo ago
    The "cleaner" commit history should be a separate layer and the actual commit history should never be altered.
- jtafurth 10mo ago
  There are several valid reasons to "falsify" commit history. - You need to remove trash commits that appear when you need to rerun CI. - You need to remove commits with that extra change you forgot. - You want to perform any other kind of rebase to clean up messages. I assume in this thread some people mean squashing from the perspective of a system like Gitlab where it's done automatically, but for me squashing can mean simply running an interactive (or fixup) and leaving only important commits that provide meaningful information to the target branch.
awesome_dude 10mo ago
Squash loses the commit history - all you end up with is merge merge merge It's harder to debug as well (this 3000line commit has a change causing the bug... best of luck finding it AND why it was changed that way in the first place. I, myself, prefer that people tidy up their branches such that their commits are clear on intent, and then rebase into main, with a merge commit at the tip (meaning that you can see the commits AND where the PR began/ended. git bisect is a tonne easier when you have that

normie3000 10mo ago

> you have to make a brand new branch for your next PR Is there overhead to creating a branch?