Fortunately, I don't squash my commits • Hacker News Board

Re: Fortunately, I don't squash my commits

#91

Post by mcv » Mon, Oct 05, 2020, 12:24 PM UTC

grumple wrote: post #82

Kihashi wrote: post #12

Earlier quoted context omitted.

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…

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 project…

I think based on this discussion I can identify one situation where squashing would be good: when you're doing repeated trial-and-error commits on a single file. That way, squashing won't turn it into 3000 lines of code, it just hides the unsuccessful attempts.

But other than that? Small commits please.

Re: Fortunately, I don't squash my commits

#92

Post by m12k » Mon, Oct 05, 2020, 12:24 PM UTC

swalsh wrote: post #84

m12k wrote: post #66

Earlier quoted context omitted.

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.

Fore removing code that's buggy in production. It's way easier to find and remove 1 commit.

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?

Re: Fortunately, I don't squash my commits

#93

Post by nailer » Mon, Oct 05, 2020, 12:24 PM UTC

Hijacking the top thread to make an important point:

- "Squash your commits" folks - yes, it's good to be able to revert a commit and remove entire features and have a readable commit history.

- "Make small granular commits" folks - yes it's good to be able to bisect and see where exactly some behaviour changed.

Rather than repeat these points (which are both true), there's a better question to be asked:

Should there be a way to have a readable history and keep individual commits? Eg, 'subcommits' etc?

- git may not have these features now, but revision control systems come and go (rcs, cvs, svn, bk, hg, git)

- Or maybe it does. Or we can implement something similar on top of git as it stands.

Discuss.

Re: Fortunately, I don't squash my commits

#94

Post by ivanhoe » Mon, Oct 05, 2020, 12:24 PM UTC

IMO the better title for the post would be "Unfortunately, I don't setup the clean environment for each of my tests"

Re: Fortunately, I don't squash my commits

#95

Post by 3np » Mon, Oct 05, 2020, 12:25 PM UTC

Joker_vD wrote: post #2

Do people out there actually squash commits? Granted, I didn't change many work places in my career, but at no place where I worked people squashed commits. What's even the point of it? It's not like people routinely read the commit history, and when they do, they really would like a complete story, not 20 gargantuan commits that contain 3 years of development.

Routinely. Common example that I can't see why anyone would take issue with:

  * Commit 1: Fix a bug
  * Commit 2: Fix linting issues with the fix discovered through CI
  * Commit 3: Remove dead/commented code introduced thrugh commit 1
  * Commit 4: Update documents as required by change

I'd always squash those into a single commit before merging into upstream.

Re: Fortunately, I don't squash my commits

#96

Post by ratww » Mon, Oct 05, 2020, 12:25 PM UTC

Joker_vD wrote: post #2

Do people out there actually squash commits? Granted, I didn't change many work places in my career, but at no place where I worked people squashed commits. What's even the point of it? It's not like people routinely read the commit history, and when they do, they really would like a complete story, not 20 gargantuan commits that contain 3 years of development.

Squashing is kind a blunt tool that is useful sometimes, but can be perfectly replaced either by crafting your commits with more care or doing interactive rebasing.

I once had to enforce to an developer that wanted to make 20 commits per PR that were titled like "wip" "wip" "wip" "fix bug" "fix mistake" "format code" in a PR that only changed like 10 lines of code in the end.

In this case, the main problem for me was that git blame became useless because this developer was touching way more lines than necessary and then undoing it using the code formatter.

Re: Fortunately, I don't squash my commits

#97

Post by reallydontask » Mon, Oct 05, 2020, 12:25 PM UTC

barrkel wrote: post #80

Squashing gets you in the habit of force pushing, and force pushing greatly increases the risk of clobbering someone's work. I've seen a lot more hours wasted on lost commits than I find credible to be wasted in slightly more verbose history. Squashing also turns cherry picked commits into merge conflicts. I'm not a fan. I can always go back to the feature PR and read the ticket details and diff commentary when I wan…

Most people at my previous place did squash merge on pr completion and we cherry picked quite successfully, so I'd be interested to know how you get to:

> Squashing also turns cherry picked commits into merge conflicts.

Re: Fortunately, I don't squash my commits

#98

Post by m12k » Mon, Oct 05, 2020, 12:27 PM UTC

bluGill wrote: post #89

m12k wrote: post #77

Earlier quoted context omitted.

> If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue I'm firmly of the belief that any benefits that squashing brings would be better achieved with better tooling, rather than by re-writing history and throwing away potential debugging information. In this case, what you need is for git to make it easier to revert 25 commits in on…

If git has a concept of branches like mercurial has it would be a lot easier as you can actually see what branch your commits attached to. (there are pros and cons of both approaches - this is a con of the git approach, I'm not knowledge about enough about esoteric details to comment on if git actually made a bad choice or just a compromise)

If you use the standard merge commit message in git, then you can still tell what branch things came from when being merged. As someone that has used both mercurial and git, the trouble with named branches (and having to remember to remove them when merging to master) is one of the reasons why I prefer git.

Re: Fortunately, I don't squash my commits

#99

Post by withinboredom » Mon, Oct 05, 2020, 12:29 PM UTC

davewritescode wrote: post #45

The reason to squash commits is more than just keeping your commit history read-able, it's about making easy to revert a feature and being able to keep history in a way that makes it simple to revert a change if you run into issues. If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue. If I had spread that endpoint across 25 commits…

> I'm a simple git revert away from fixing the issue.

I don’t think this is true /just/ for squashed commits as you can simply revert the merge. Squashing is also bad, because you’ll lose the history of the bug fix that prevented the deployment. Or at least someone will have a hell of a time deciphering the PR to reintegrate the original change and your bug fix.

After a few days, weeks, or months, the argument loses even more water because code will likely depend on the commit in question.

War story: there was a time someone accidentally deleted a multi-gb table in production. The table would take hours to delete and replicate globally, so the entire company spent at least an hour deleting the feature from production to stop the database errors. There wasn’t any reverting of original commits. No one had time for that.

Re: Fortunately, I don't squash my commits

#100

Post by gmfawcett » Mon, Oct 05, 2020, 12:29 PM UTC

Mazzen wrote: post #59

twic wrote: post #54

Earlier quoted context omitted.

> If I had spread that endpoint across 25 commits, I'd have to actually debug the issue in QA and figure out what I broke No, you could just revert the entire lot in one go.

that's not a valid argument. How do you identify "the lot"?

There's an obvious upper bound. If you can't identify the last in-prod version that worked, and the first in-prod version that failed, then you have bigger problems than deciding whether to squash your commits.