5 ms·

In my experience the squashing crowd is much louder and cares more about squashing than the crowd who prefers to see every commit. I hate squashing, but I've be

In my experience the squashing crowd is much louder and cares more about squashing than the crowd who prefers to see every commit. I hate squashing, but I've been beaten down into doing it many times because in the end it doesn't actually matter. The merge commits everywhere argument falls apart if you use log --no-merges. The shitty commit messages argument is solved by not allowing shitty commit messages. The "fixed typo", "oops left TODO", "another typo" chain of commits argument is solved by telling people to not do a million commits like that and IMO those should be squashed. The clean history argument is solved when you don't allow the useless "fixing typo" commits in feature-xyz branches. Your history should be clean and contain a history of the progress that was made. But ultimately the easiest way to solve all these problems is to force everyone to squash. You only have to police people on a single commit and people don't have to learn about options like --no-merges.

Izkata 4y ago
> I hate squashing, but I've been beaten down into doing it many times because in the end it doesn't actually matter. For those of us on maintenance teams, who actually have to dig in to the history to figure out what happened, not squashing matters a lot.
- evandale 4y ago
  You'll have to elaborate with specifics because in my experience it doesn't matter if there's 100 or 10000 commits - git bisect works great in both instances.
  - RadiozRadioz 4y ago
    Bisect will let you find the big squash commit that caused the regression, but lots of the information about why the change happened was lost during the squash. Often it's sufficient to just know the broad feature that the change was in aid of, but you're out of luck if you're diagnosing anything subtle. Bisect works better with smaller commits.
  - Izkata 4y ago
    It works, but it works better when you have the original 10000 commits. You can tell exactly what the committer was attempting when the bug was introduced. It may have been as a fix to something else, it may have been a typo when linting, it may even have been been intentional and the bug report is wrong. Other comments I made on another recent git post: https://news.ycombinator.com/item?id=33395616 https://news.ycombinator.com/item?id=33395616 https://news.ycombinator.com/item?id=33392624 https://news.ycombinator.com/item?id=33392624
    - chociej 4y ago
      None of the opinions described in this thread can fix the problem of ultimately having too many or too few commits, whatever norms are enforced. Squashing errs toward too few, not squashing errs toward too many. Probably the ideal is that a PR has meaningful, thoughtful commits which each contain a coherent, self-contained increment of functionality.
    - groestl 4y ago
      It may be the last thing they did on this day and the commit message reads "wip".
      - Izkata 4y ago
        And if that's where we end up while bug-hunting, we know it was caused by an unfinished thought, is akin to the typo case above, and should be fixable without much concern over what else it may break since it wasn't introduced while fixing something else.
        evandale 4y ago
        That's exactly why I like multiple commits similar to how I described. Maybe this is the silver bulletpoint that can convert squashers? https://news.ycombinator.com/item?id=33536876 https://news.ycombinator.com/item?id=33536876 >One of those small typo fixes could introduce a bug and multiple commits makes it easier to track down. Blame would pinpoint it exactly - you'll see Bob's "Fix a typo" commit instead of being buried in Bob's "Add trucks to the game" commit. That saves you from having to go look at the PR or diff and to figure out why Bob renamed cares to cars.
groestl 4y ago
> is solved by telling people to not do a million commits like that > don't allow the useless "fixing typo" commits This sounds like a much much more heavy handed approach than: I don't care what you do on your feature branches, just squash your commits to master and write a nice commit message explaining what you did. IMHO, all your rules do is increase inertia of people to fix typos.
- evandale 4y ago
  It's a bit heavy handed, but I believe the rules are more like best practices. If you're fixing typos in new code I see no reason to have the history of introducing the typo and then fixing it. If you've come across a typo in a file you're editing then by all means make that typo fix in its own commit. It gets worse when you start fixing typos in files unrelated to your fix. One of those small typo fixes could introduce a bug and multiple commits makes it easier to track down. Blame would pinpoint it exactly - you'll see Bob's "Fix a typo" commit instead of being buried in Bob's "Add trucks to the game" commit. That saves you from having to go look at the PR or diff and to figure out why Bob renamed cares to cars.
  - lamontcg 4y ago
    > It gets worse when you start fixing typos in files unrelated to your fix. That does not go into the PR and someone should make you split that out into a code-cleanup PR and it shouldn't pass review.

Izkata 4y ago

> I hate squashing, but I've been beaten down into doing it many times because in the end it doesn't actually matter. For those of us on maintenance teams, who actually have to dig in to the history to figure out what happened, not squashing matters a lot.

evandale 4y ago
You'll have to elaborate with specifics because in my experience it doesn't matter if there's 100 or 10000 commits - git bisect works great in both instances.
- RadiozRadioz 4y ago
  Bisect will let you find the big squash commit that caused the regression, but lots of the information about why the change happened was lost during the squash. Often it's sufficient to just know the broad feature that the change was in aid of, but you're out of luck if you're diagnosing anything subtle. Bisect works better with smaller commits.
- Izkata 4y ago
  It works, but it works better when you have the original 10000 commits. You can tell exactly what the committer was attempting when the bug was introduced. It may have been as a fix to something else, it may have been a typo when linting, it may even have been been intentional and the bug report is wrong. Other comments I made on another recent git post: https://news.ycombinator.com/item?id=33395616 https://news.ycombinator.com/item?id=33395616 https://news.ycombinator.com/item?id=33392624 https://news.ycombinator.com/item?id=33392624
  - chociej 4y ago
    None of the opinions described in this thread can fix the problem of ultimately having too many or too few commits, whatever norms are enforced. Squashing errs toward too few, not squashing errs toward too many. Probably the ideal is that a PR has meaningful, thoughtful commits which each contain a coherent, self-contained increment of functionality.
  - groestl 4y ago
    It may be the last thing they did on this day and the commit message reads "wip".
    - Izkata 4y ago
      And if that's where we end up while bug-hunting, we know it was caused by an unfinished thought, is akin to the typo case above, and should be fixable without much concern over what else it may break since it wasn't introduced while fixing something else.
      - evandale 4y ago
        That's exactly why I like multiple commits similar to how I described. Maybe this is the silver bulletpoint that can convert squashers? https://news.ycombinator.com/item?id=33536876 https://news.ycombinator.com/item?id=33536876 >One of those small typo fixes could introduce a bug and multiple commits makes it easier to track down. Blame would pinpoint it exactly - you'll see Bob's "Fix a typo" commit instead of being buried in Bob's "Add trucks to the game" commit. That saves you from having to go look at the PR or diff and to figure out why Bob renamed cares to cars.

groestl 4y ago

> is solved by telling people to not do a million commits like that > don't allow the useless "fixing typo" commits This sounds like a much much more heavy handed approach than: I don't care what you do on your feature branches, just squash your commits to master and write a nice commit message explaining what you did. IMHO, all your rules do is increase inertia of people to fix typos.

evandale 4y ago
It's a bit heavy handed, but I believe the rules are more like best practices. If you're fixing typos in new code I see no reason to have the history of introducing the typo and then fixing it. If you've come across a typo in a file you're editing then by all means make that typo fix in its own commit. It gets worse when you start fixing typos in files unrelated to your fix. One of those small typo fixes could introduce a bug and multiple commits makes it easier to track down. Blame would pinpoint it exactly - you'll see Bob's "Fix a typo" commit instead of being buried in Bob's "Add trucks to the game" commit. That saves you from having to go look at the PR or diff and to figure out why Bob renamed cares to cars.
- lamontcg 4y ago
  > It gets worse when you start fixing typos in files unrelated to your fix. That does not go into the PR and someone should make you split that out into a code-cleanup PR and it shouldn't pass review.