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

Re: Fortunately, I don't squash my commits

#301

Post by renewiltord » Mon, Oct 05, 2020, 9:08 PM UTC

m12k wrote: post #77

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…

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

git-revert supports ranges if you've used any version within the last couple of years.

Re: Fortunately, I don't squash my commits

#302

Post by sys_64738 » Mon, Oct 05, 2020, 9:11 PM UTC

When you commit your fully tested and bug free code to the master branch, developer WIP commits should be squashed. It's one thing to commit your WIP commits to a toy git master branch you control but as soon as others look at it, it doesn't scale.

I've asked this question in job interviews. It's amazing what people say.

Re: Fortunately, I don't squash my commits

#303

Post by renewiltord » Mon, Oct 05, 2020, 9:13 PM UTC

jasonkester wrote: post #200

jefftk wrote: post #192

> Had this happened in a code base with a 'nice history' (as the squash proponents like to present it), that small commit would have been bundled with various other commits. This is a misunderstanding of what proponents of commit squashing advocate. Often, when working, you end up with multiple commits which represent a single change: remove debug logging and fix bug more logging debugging typo Squashing these commit…

I can only sit in amazement as I read this thread, watching seemingly smart people advocating throwing away history for the sake of tidiness. It's maddening. Those are four commits. That's what happened. It does not matter that it's untidy. It's your history. Just leave it. It will save you a lot of work some day when you need to find the error you introduced when you accidentally removed one too many lines on that "…

I have done one or the other. My personal experience is that intermediate commits provide low value. YMMV but I now know what works for me.

I definitely leave in commit A and a revert of commit A if I think it'll be useful.

The way I see it is I'm leaving breadcrumbs for myself for later. It's obvious that a sequence of keystrokes is useless (and most IDEs will undo a large number at once - correct behaviour) and that no history is useless so you have to find the thing that works for yourself or your team wherever.

Re: Fortunately, I don't squash my commits

#304

Post by nemetroid » Mon, Oct 05, 2020, 9:24 PM UTC

ezst wrote: post #265

LanternLight83 wrote: post #186

Earlier quoted context omitted.

I've always been frustrated by losing my topic branches once they're merged and deleted, but can't bring myself to clutter my local branches keeping them around, to the point of tagging them just to keep track- I like the sound of your argument and will look into how fast-forward effect my commit history vs. a merge commit, thx c:

This is where you realize that what's killing git is that git has no concept of branches whatsoever. Such a merge isn't "merging A into B (plus shove metadata as string into the commit message)", it is "merging A and B together", which is topologically identical, but semantically very distinct. That's why Mercurial (esp. with evolve and topics) has forever my preference over git.

That's not completely true. There's an order to the parents of a merge commit, and by convention the first parent is the one that was merged "into".

Re: Fortunately, I don't squash my commits

#305

Post by Gaelan » Mon, Oct 05, 2020, 9:41 PM UTC

falcolas wrote: post #129

Gaelan wrote: post #88

Earlier quoted context omitted.

I'm no squash fan either, but git very rarely actually clobbers data. (As long as it's been committed at some point, and wasn't just sitting in the working tree.) `git reflog` can get back pretty much anything, as long as it happened relatively recently.

Until a garbage collection process trims those. You may control such on your local machine, but you don’t on the remote repo.

That’s why I said “as long as it happened relatively recently.” Of course, the commits in question should exist locally on someone’s machine, so we shouldn’t need to worry about what the remote does.

Re: Fortunately, I don't squash my commits

#306

Post by nemetroid » Mon, Oct 05, 2020, 9:42 PM UTC

jasonkester wrote: post #200

jefftk wrote: post #192

> Had this happened in a code base with a 'nice history' (as the squash proponents like to present it), that small commit would have been bundled with various other commits. This is a misunderstanding of what proponents of commit squashing advocate. Often, when working, you end up with multiple commits which represent a single change: remove debug logging and fix bug more logging debugging typo Squashing these commit…

I can only sit in amazement as I read this thread, watching seemingly smart people advocating throwing away history for the sake of tidiness. It's maddening. Those are four commits. That's what happened. It does not matter that it's untidy. It's your history. Just leave it. It will save you a lot of work some day when you need to find the error you introduced when you accidentally removed one too many lines on that "…

> Just leave it. It will save you a lot of work some day when you need to find the error you introduced when you accidentally removed one too many lines on that "remove debug logging" commit.

I understood the parent as "remove debug logging" removing what was introduced by the previous two commits. In this case, squashing the commits will actually make the issue _much_ more obvious, since the accidentally removed line now stands out by itself without the clutter of the back-and-forth changes.

Re: Fortunately, I don't squash my commits

#307

Post by _p1nd » Mon, Oct 05, 2020, 9:59 PM UTC

I've really never understood this obsession with "preserving" history. When I work on a feature or bug I tend to commit often, because it's cheap, and it can save my ass if I go in a bad direction and break something that used to work in one of my previous commits. I subscribe to a code fast philosophy, and work quickly to explore the space, find unknowns, get a working solution, write tests, and do final cleanup, docs, and optimize if needed. As such this would be a common commit history for me that would end up in a small PR. A large PR for me might have 50+ commits.

- initial prototype of feature x, mostly working

- feature x working as intended in requirements

- fixed edge cases not originally identified when thinking about feature x

- rearchitect feature x a bit now that it's better understood

- write tests for feature x, most pass

- get all feature x unit tests pass

- a few more test cases for feature x

- and a couple of integration tests for feature x

- code cleanup for feature x

- fix typo from last code cleanup resulting in bug

- better docs for feature x

- fix typos in feature x docs

- update main readme to include notes about feature x

Can anyone explain to me the value in preserving this history, because I'm just not seeing it, and it would completely muddy up the overall git history. There's tons of intermediate work we're not concerned about preserving, like the notes I scribble on paper, so why are we so concerned about preserving all these commits? I admit there's a small chance it's useful in rare circumstances, but I'd rather optimize for the common scenario.

Re: Fortunately, I don't squash my commits

#308

Post by notdonspaulding » Mon, Oct 05, 2020, 10:16 PM UTC

ezst wrote: post #265

LanternLight83 wrote: post #186

Earlier quoted context omitted.

I've always been frustrated by losing my topic branches once they're merged and deleted, but can't bring myself to clutter my local branches keeping them around, to the point of tagging them just to keep track- I like the sound of your argument and will look into how fast-forward effect my commit history vs. a merge commit, thx c:

This is where you realize that what's killing git is that git has no concept of branches whatsoever. Such a merge isn't "merging A into B (plus shove metadata as string into the commit message)", it is "merging A and B together", which is topologically identical, but semantically very distinct. That's why Mercurial (esp. with evolve and topics) has forever my preference over git.

This.

I can't figure out how to explain to Junior Devs (who have only ever known git), that they have a concept of a branch in their head that doesn't match the concept their tool of choice is giving them.

We talk about "branches" as logical sets of changes. We give them meaningful names, we construct the concept of Pull Requests and code reviews around the concept of a branch. We later refer to Feature X as having landed in master from branch Y. But git doesn't have any of those semantics. It has lots of ways of dealing with commits, and a facade of a branching model is just one more way of dealing with commits. Branches are not a first-class concept in git. And certainly not like they are in our minds.

However, git is amazing at what it does! And if I was running the world's most popular OS kernel development team and was expecting to receive hundreds of patches a day via email from developers in whom I have limited trust, I would definitely start with git's model and change the way my brain works to match its semantics.

Instead, I find myself on a small team of high-trust coworkers who all talk about branches as if they really exist in our git history, and somehow I'm the crazy one for pointing out that every time we hit a problem with this mismatch the fact that we're using git is the reason that we can't have nice things.

Re: Fortunately, I don't squash my commits

#309

Post by waffletower » Mon, Oct 05, 2020, 11:24 PM UTC

sys_64738 wrote: post #302

When you commit your fully tested and bug free code to the master branch, developer WIP commits should be squashed. It's one thing to commit your WIP commits to a toy git master branch you control but as soon as others look at it, it doesn't scale. I've asked this question in job interviews. It's amazing what people say.

Sad that you use your strict etiquette as a leading question in job interviews. How do you know that code is bug free when you commit to master? What qualifies as fully tested? If you are convinced that there are absolute and known answers to these questions I would suggest analyzing your logic again.

Re: Fortunately, I don't squash my commits

#310

Post by elgaard » Mon, Oct 05, 2020, 11:38 PM UTC

outworlder wrote: post #283

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.

More often than not, lots of small commits, with incomplete changes, will make git bisect completely useless. It takes someone that's, at the same time, making 'messy' commits with horrible messages, but also diligent enough to never commit any breaking changes.

Not really. With git bisect you know what you are looking for. So even if you did make a commit with e.g., a missing semicolon you can still call it "good" because it did not cause the problem your are trying to debug.