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

Re: Fortunately, I don't squash my commits

#291

Post by windsurfer » Mon, Oct 05, 2020, 7:23 PM UTC

yuliyp wrote: post #287

hawkice wrote: post #278

Earlier quoted context omitted.

I think you're missing out on the main advantage the article points out: lots of small commits, even with terrible error messages, let you use tools like git bisect to find bugs. Squashed commits mean you're looking through more code, and above some small size, it won't be obvious what the issue is.

Bisects only work if every intermediate commit is a working state.

If what you're looking for is a specific breakage or result that doesn't depend on something "working", then each commit does not necessarily need to be working. You may also want to read about the git-bisect feature "old/new" which could help if you're just looking for a change and not a breakage.

Re: Fortunately, I don't squash my commits

#292

Post by waffletower » Mon, Oct 05, 2020, 7:30 PM UTC

Some software engineers can be fanatical and rule-bound; commit etiquette is merely one milieu where rigid thinking can be applied, and with the usual detriment. I applaud the author for presenting a clear case how reality is more complex than many beginning to intermediate developers would like it to be when it comes to commit history.

Re: Fortunately, I don't squash my commits

#293

Post by pkamb » Mon, Oct 05, 2020, 7:48 PM UTC

Vinnl wrote: post #204

I usually understand "squash" to mean "bundle everything in a PR into a single commit". Which can indeed break bisect workflows. There's a middle ground though: rebase your commits, but not necessarily into a single one. Before I submit a PR, I rebase my branch (which has lots of small commits, some of which undo previous work or are a work-in-progress), and make sure that every commit is as small as it can be withou…

An easy way to do this is to perform a 'mixed reset' from the tip of your branch back to the mainline commit where you started work. (Use a new branch, so that your original branch "backs up" the work.)

This will leave all of the final changes in the index, "squashing" any churn. From there, individually stage lines/chunks into a small handful of atomic commits for the PR.

Re: Fortunately, I don't squash my commits

#294

Post by mixmastamyk » Mon, Oct 05, 2020, 7:54 PM UTC

corytheboyd wrote: post #217

Vinnl wrote: post #204

I usually understand "squash" to mean "bundle everything in a PR into a single commit". Which can indeed break bisect workflows. There's a middle ground though: rebase your commits, but not necessarily into a single one. Before I submit a PR, I rebase my branch (which has lots of small commits, some of which undo previous work or are a work-in-progress), and make sure that every commit is as small as it can be withou…

I wish more people would naturally come to this conclusion in their careers, but many people I have worked with just don’t care about maturing their git disciplines. All it takes is one teammate who thinks it’s a waste of time to undo the progress of everyone else. For context, my career has been in web development start ups, which generally reward the cavalier and tolerate the careful.

> All it takes is one teammate who thinks it’s a waste of time to undo the progress of everyone else.

If a strategy demands perfection, it sounds like wishful thinking honestly.

Re: Fortunately, I don't squash my commits

#295

Post by mixmastamyk » Mon, Oct 05, 2020, 8:19 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.

That's not how it works, really. A simplified workflow:

You take bug or enhancement of a couple of points, work on it on its own branch, then merge req+squash the mostly noise commits into a develop/master at once.

A chunk is approximately 3 days, not 3 years. For forward-looking projects, it saves time and works well. "Enterprisey" projects maintaining legacy branches are less well served.

Re: Fortunately, I don't squash my commits

#296

Post by mixmastamyk » Mon, Oct 05, 2020, 8:25 PM UTC

spdionis wrote: post #280

vonmoltke wrote: post #229

Earlier quoted context omitted.

It really depends on where you work and how your company's repo is organized. For instance, where I work 20 squash commits would represent, at most, 10 minutes worth of commits to the monorepo. Not squashing on merge would quickly turn thousands of daily commits into tens of thousands. It's already impractical to find suspect commits via git, and we typically use our code review tool to find the change that broke som…

You are definitely correct. People who argue against squashing have not worked on 10+ years old actively developed repositories, or in big enough teams. A commit is a change. A change has a ticket. A ticket is a small piece of work that does not result in 3k changed lines. This ensures that the change rationale is fully documented and easily identifiable. Nobody needs those "fixed typo" commits. Nor the "implemented…

Agreed, I regularly add comments later as well. Understanding often comes after the code works.

I could obsessively fiddle with every commit like an artesenal snowflake, or I could click the squash checkbox on the request.

Re: Fortunately, I don't squash my commits

#297

Post by mixmastamyk » Mon, Oct 05, 2020, 8:37 PM UTC

NateEag wrote: post #177

ZephyrBlu wrote: post #36

Earlier quoted context omitted.

Navigate to PR -> Restore Branch -> `git checkout ` How is this annoying or time consuming? It takes less effort than adding, committing and pushing changes.

Because with a test suite, git bisect, and a history that's been reasonably well cared for, I can just tell git "find me the bug" and go do something else until it's done. I don't like having to go fiddle manually for that to work. Ideally you have CI set up so the average test failure email points you to the small patch that broke it. For bugs from the wild that doesn't work, obviously, but I still prefer less frict…

Sounds like you've moved the work forward, where it always has to be done. Rather than doing it in a lazy manner, where most instances can be avoided. Is that a good trade-off?

Re: Fortunately, I don't squash my commits

#298

Post by kelnos » Mon, Oct 05, 2020, 8:38 PM UTC

Vinnl wrote: post #275

im3w1l wrote: post #235

Earlier quoted context omitted.

It's not fun if you rebase, and realize that every single one of your many commits need to hand-merged.

But you need to deal with those conflicts before merging anyway? And they're a lot easier to deal with in the context of the individual commits than when dealing with one big merge commit, I find.

The issue is that when you rebase, each commit in the chain gets re-applied, one by one. If you change something in an earlier commit that affects later commits, you could end up having to fix the same or similar conflicts several times before the rebase finishes (even with git's conflict resolution cache).

In contrast, if you instead merge, you only have to resolve conflicts once, for the merge commit.

That being said, I tend to be very fastidious about cleaning up my history before pushing, even if it means tedious, repetitive conflict resolution. But I do understand that other people might not think it's worth the trouble.

Re: Fortunately, I don't squash my commits

#299

Post by kelnos » Mon, Oct 05, 2020, 8:42 PM UTC

jerf wrote: post #150

_-___________-_ wrote: post #112

The most striking thing in this story for me has nothing to do with commit squashing. Faced with something that suddenly stopped working, the developer went on a wild goose chase, first decoding their JWT -- presumably the same one that "used to work" -- then looking for possible framework bugs or misconfiguration, before looking at their own code, the single most likely place that the bug would be. They even linked…

"went on a wild goose chase" Because 19 times out of 20, that "wild goose chase" finds the bug faster. As there is no perfect debugging methodology, sometimes whatever method you use will go wrong and you'll end up on the bottom of your list of things to check, or worse, right off the bottom of the list. (Those are some bad days.) That is not, itself, proof that your list is broken. After all, the author found this a…

> Because 19 times out of 20, that "wild goose chase" finds the bug faster.

This particular goose chase involved digging into everything except the developer's own code. 19 times out of 20, the issue is with your own code. OP even acknowledged this in the blog post, but his actions didn't align with that acknowledgement.

Re: Fortunately, I don't squash my commits

#300

Post by kelnos » Mon, Oct 05, 2020, 8:51 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.

It's a mix where I work. Most people aren't at all tidy with their commit history, and I'll often see a PR with a fairly small final diff (maybe a couple hundred lines changed total) with several useless one-word commit messages like "fix".

And then after the PR has gone through review, most people tack on extra commits with equally-useless commit messages like "addressing feedback".

It's infrequent that I see PRs with commit histories that actually chronicle the history of the change itself; it's more a chronicle of the developer's changing thought processes as they try different things, go down blind alleys, change approaches several times.

Most of the individual commits have test suite failures and some of them don't even compile, so it's impossible to bisect across them if an issue is later found.

In those cases, I wish people would just squash (and some do, where I work). Yes, you lose information and separation, but I'd rather have one large working commit than 15 small broken commits followed by one working commit. Ideally people would curate things before submitting their PR, but I've found that most people just don't care, or don't understand git well enough to even attempt to do it.

Sometimes I toy around with the idea of trying to teach people (what I consider) better practices, and insist they are followed, but we all have a limited amount of social capital in our workplaces, and I'm not convinced this is something worth spending it on.