6 ms·

I find the individual commits on feature branches to be more noise than signal after they are merged. They can be useful during review, sometimes, but mostly I

I find the individual commits on feature branches to be more noise than signal after they are merged. They can be useful during review, sometimes, but mostly I want a cleaner history. > they really would like a complete story, not 20 gargantuan commits that contain 3 years of development That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge/squash commits, not 20 large ones.

pbalau 6y ago
If you look at the PRs list, you will have a clean and tidy history.
- alkonaut 6y ago
  Yep, but many tools (most notoriously git bisect, famous from the article) doesn't understand "--first-parent" which is ridiculous. The only way to have a clean history that all tools accept is clean, is basically to outlaw merges.
mcny 6y ago
> That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge/squash commits, not 20 large ones. With the people I've worked with, I'd say most don't commit at all until they think the code is "ready" and they commit all at once. In the teams I've worked with, squashing vs not squashing isn't the question. I just want them to commit/push as soon as they've hit a stopping point or at least once a day. Maybe the people you've worked with are good with git but I am not that good with git. I'm still stuck on 6: Resolve a merge conflict on git exercises because I made one too many commits and now the exercise says I have too many commits. https://gitexercises.fracz.com/ https://gitexercises.fracz.com/ Previously on HN: https://news.ycombinator.com/item?id=24671638 https://news.ycombinator.com/item?id=24671638
- mkesper 6y ago
  You need to squash your commits, then: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
m12k 6y ago
What do you use your "cleaner history" for? I seldom go back and look at historical commits unless I'm debugging, in which case I'd prefer to know what actually happened at the time with as much information preserved as possible.
- swalsh 6y ago
  Fore removing code that's buggy in production. It's way easier to find and remove 1 commit.
  - falcolas 6y ago
    Isn’t that what rolling back releases for? i.e. revert the container (or whatever your unit of release is) to the previous version? If you’re removing individual commits and re-releasing (rolling forward), you’re still at risk of being down, because you’re not going back to a known good release.
  - m12k 6y ago
    And what do you think about the linked article that shows how it's easier to find exactly which code is buggy if you have it in small commits instead of one big squashed one?
    - swalsh 6y ago
      Good, do what he did too... but in a feature branch.
- byte1918 6y ago
  A clean history with proper commit names can work as a change log for you app. We actually did that and it worked quite well. In Azure DevOps the release pipelines have access to the list of commits since the previous release so one only has to simply take the titles of those commits to build it.
  - nikisweeting 6y ago
grumple 6y ago
When you have to find a subtle one line breakage that happened years ago, you’ll be happy that you had a single commit with 30 lines of code instead of a squashed commit with 3000. It makes it much easier to isolate the case of a problem and fix it in many cases. I’m asked “how long has this been broken and what caused it?” and answer it via git blame or bisect probably every few weeks. This is life on legacy projects.
- delecti 6y ago
  I think you just highlighted one source of the disagreement. Nobody on any team I work with would accept a PR with 3000 lines of change. Each team had a policy, whether formal or informal, to break large work items across PRs so they were more easily reviewable. I would say that 300 lines changed is getting towards the bigger end of what we would accept. If your choice is between 30 or 3000 lines changed per commit, then for sure I'd pick 30, but above either I think a 300 line limit is more sensible.
  - grumple 6y ago
    Yeah, that’s nice in theory, but in practice the situation is often less ideal. Some features, partially implemented, would break existing functionality if not completed, and merging those upstream prior to total completion is therefore impossible. And on the other side of things, some environments and features require large, systemic changes. This is, surely, an organizational failing, but one that we must adapt to.
    - delecti 6y ago
      Then that's the other half of my point. If you can limit PRs to 300, then merging PRs into a single commit is better. If you can't, then maybe squashing isn't ideal.
    - Aeolun 6y ago
      Convert all the JS files to Typescript, suddenly you get blame ed for everything.
- 6y ago
Joker_vD 6y ago
But surely you would like to squash those merge commits as well, at some points? Hundreds of merge/squash commits pollute the history almost as much as thousands of normal commits, so after a large feature set is done, one should just squash all of it into a single commit. That way, you can have "nice" development history where tags for the old versions are redundant since they match commits one for one: $ git branch main $ git log --oneline abcd000 (HEAD -> main) version 5.2 abcd111 version 5.1 abcd222 version 5.0 ef01234 version 4.7 9876543 version 3.4 fedb123 version 2.12 dedc456 version 1.128
- DarkWiiPlayer 6y ago
  The git log isn't a release history, it's a development history. Squashing commits throws away context that could be useful in any number of ways. There's nothing wrong with squashing a bunch of commits that really should have been a single commit from the start: - Update X to do Y - Fix typo in X - Add "foo" option to X for when Y is a bar But most of the time "features" consist of many changes: we add one function we're going to need, then another, then yet another... Then we change an API to expose the new functions, then extend the UI to make room for it and finally make put it into the application and pull all the strings together. Squashing all these into one commit is just a bad idea. You can always do git rebase -i before merging to do minor fixups or even reorder your commits (like when you notice a typo after several other commits), but completely removing all granularity... just no.

pbalau 6y ago

If you look at the PRs list, you will have a clean and tidy history.

alkonaut 6y ago
Yep, but many tools (most notoriously git bisect, famous from the article) doesn't understand "--first-parent" which is ridiculous. The only way to have a clean history that all tools accept is clean, is basically to outlaw merges.

mcny 6y ago

> That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge/squash commits, not 20 large ones. With the people I've worked with, I'd say most don't commit at all until they think the code is "ready" and they commit all at once. In the teams I've worked with, squashing vs not squashing isn't the question. I just want them to commit/push as soon as they've hit a stopping point or at least once a day. Maybe the people you've worked with are good with git but I am not that good with git. I'm still stuck on 6: Resolve a merge conflict on git exercises because I made one too many commits and now the exercise says I have too many commits. https://gitexercises.fracz.com/ https://gitexercises.fracz.com/ Previously on HN: https://news.ycombinator.com/item?id=24671638 https://news.ycombinator.com/item?id=24671638

mkesper 6y ago
You need to squash your commits, then: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

m12k 6y ago

What do you use your "cleaner history" for? I seldom go back and look at historical commits unless I'm debugging, in which case I'd prefer to know what actually happened at the time with as much information preserved as possible.

swalsh 6y ago
Fore removing code that's buggy in production. It's way easier to find and remove 1 commit.
- falcolas 6y ago
  Isn’t that what rolling back releases for? i.e. revert the container (or whatever your unit of release is) to the previous version? If you’re removing individual commits and re-releasing (rolling forward), you’re still at risk of being down, because you’re not going back to a known good release.
- m12k 6y ago
  And what do you think about the linked article that shows how it's easier to find exactly which code is buggy if you have it in small commits instead of one big squashed one?
  - swalsh 6y ago
    Good, do what he did too... but in a feature branch.
byte1918 6y ago
A clean history with proper commit names can work as a change log for you app. We actually did that and it worked quite well. In Azure DevOps the release pipelines have access to the list of commits since the previous release so one only has to simply take the titles of those commits to build it.
- nikisweeting 6y ago

grumple 6y ago

When you have to find a subtle one line breakage that happened years ago, you’ll be happy that you had a single commit with 30 lines of code instead of a squashed commit with 3000. It makes it much easier to isolate the case of a problem and fix it in many cases. I’m asked “how long has this been broken and what caused it?” and answer it via git blame or bisect probably every few weeks. This is life on legacy projects.

delecti 6y ago
I think you just highlighted one source of the disagreement. Nobody on any team I work with would accept a PR with 3000 lines of change. Each team had a policy, whether formal or informal, to break large work items across PRs so they were more easily reviewable. I would say that 300 lines changed is getting towards the bigger end of what we would accept. If your choice is between 30 or 3000 lines changed per commit, then for sure I'd pick 30, but above either I think a 300 line limit is more sensible.
- grumple 6y ago
  Yeah, that’s nice in theory, but in practice the situation is often less ideal. Some features, partially implemented, would break existing functionality if not completed, and merging those upstream prior to total completion is therefore impossible. And on the other side of things, some environments and features require large, systemic changes. This is, surely, an organizational failing, but one that we must adapt to.
  - delecti 6y ago
    Then that's the other half of my point. If you can limit PRs to 300, then merging PRs into a single commit is better. If you can't, then maybe squashing isn't ideal.
  - Aeolun 6y ago
    Convert all the JS files to Typescript, suddenly you get blame ed for everything.
6y ago

Joker_vD 6y ago

But surely you would like to squash those merge commits as well, at some points? Hundreds of merge/squash commits pollute the history almost as much as thousands of normal commits, so after a large feature set is done, one should just squash all of it into a single commit. That way, you can have "nice" development history where tags for the old versions are redundant since they match commits one for one: $ git branch main $ git log --oneline abcd000 (HEAD -> main) version 5.2 abcd111 version 5.1 abcd222 version 5.0 ef01234 version 4.7 9876543 version 3.4 fedb123 version 2.12 dedc456 version 1.128

DarkWiiPlayer 6y ago
The git log isn't a release history, it's a development history. Squashing commits throws away context that could be useful in any number of ways. There's nothing wrong with squashing a bunch of commits that really should have been a single commit from the start: - Update X to do Y - Fix typo in X - Add "foo" option to X for when Y is a bar But most of the time "features" consist of many changes: we add one function we're going to need, then another, then yet another... Then we change an API to expose the new functions, then extend the UI to make room for it and finally make put it into the application and pull all the strings together. Squashing all these into one commit is just a bad idea. You can always do git rebase -i before merging to do minor fixups or even reorder your commits (like when you notice a typo after several other commits), but completely removing all granularity... just no.