Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fortunately, I don't squash my commits

blog.ploeh.dk

Post reply on HN
Print view View original

311–320 of 333 posts

Re: Fortunately, I don't squash my commits

#311

Post by blntechie »

Unrelated to git but as soon as the authorization was failing with even a correct JWT token, the first thing I would have looked at is the AuthorizeHandler and registration stuff in Startup.cs.

It got crystal clear when the breakpoint was not hit or when removing the Authorize attribute worked.

The repeated saying of my tests were passing and it must be the framework kind of annoyed me as the Authorize attribute is not magic and there need to be wiring stuff which need to be written.

Re: Fortunately, I don't squash my commits

#312

Post by sys_64738 »

waffletower wrote: post #309
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.

Not squashing commits doesn't scale. That's the key to discern who has experience on large projects. Intermediate commits are of no interest to a codebase with dozens of developers.

Re: Fortunately, I don't squash my commits

#313

Post by nimblegorilla »

acdha wrote: post #284
nimblegorilla wrote: post #174

Earlier quoted context omitted.

Seems like the real bug was in his handling of JwtSecurityTokenHandler. He claims to be an expert on dependency injection with two decades of automated testing experience. I wonder what was so hard about writing a test to cover this scenario?

It's not a good look to trash someone's career because they made a mistake. This happens to everyone everywhere — the only question is how well you handle it.

Point is that `squash` is a useful tool used by many other successful professionals. I'm allowed to disagree with the author's opinion of the root cause of his bug and the factors that made it hard or easy to debug.

Re: Fortunately, I don't squash my commits

#314

Post by SassyGrapefruit »

hinkley wrote: post #259
SassyGrapefruit wrote: post #239

>I've always disliked Git's squash feature, and here's one of the many reasons to dislike it. 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 question always boils down to this metric. Which happen more often... 1. A circumstance arises where the dynamics of fine grained commits make the pr…

Maintaining safety equipment takes time and effort we could be using for something else. But we do it anyway because when we do need it, it trumps all other concerns. It’s better for people to get comfortable dealing with commit history than kicking the can down the road by getting the abridged edition. You’re infantilizing your coworkers, and hamstringing the people who do deep root cause analysis at the same time.

I don't understand your reasoning.

>Maintaining safety equipment takes time and effort we could be using for something else

You haven't established the relationship between"safety equipment" and your preferred style commit history. You haven't shown one to be safer than another.

>It’s better for people to get comfortable dealing with commit history than kicking the can down the road by getting the abridged edition.

I do deal with the commit history just a simpler, more meaningful version. If you could write code perfectly with as little effort as possible wouldn't you do it? Well we're not perfect but we can go back and change the history so it looks like we were :)

Re: Fortunately, I don't squash my commits

#315

Post by BeetleB »

aayjaychan wrote: post #227
BeetleB wrote: post #194

Mercurial's evolve extension has fold , which is similar to squash . However, it still has all the individual commits if you wish to examine them - they're just "hidden" and the usual commands (logs, etc) will show just the squashed commit.

Git does hide the old commits as well. What git doesn't do is track which commits are replaced by which. So sharing mutable history and seeing how a commit evolved over time requires more heuristic than necessary.

I was under the impression that those individual commits eventually get lost (i.e. may be in the reflog or not sent to the server, etc).

With Mercurial's evolve, the hidden commits are always there. When you push/clone, etc they get sent around.

Re: Fortunately, I don't squash my commits

#316

Post by saagarjha »

maccard wrote: post #263
saagarjha wrote: post #220

Earlier quoted context omitted.

You’re creating a false dichotomy. When people say “squash your commits”, the don’t mean “squash your entire repo into one commit”, they mean “get rid of you ‘typo’, ‘typo fix’ commits”. Your commits should still be small and self-contained.

Actually I think you're creating a false dichotomy. How many people are commiting dozens of "typo/fix build" commits and then squashing just those? In reality people are squashing the iteration process of "add an X, add a Y, remove the X because it didn't work, and add a Z instead of an X and Y" into "Add a Z" If you're simply talking about removing "fix typo" commits, then just don't. Just ignore them. You don't nee…

When that happens, I usually stick in a comment about it. Generally anything worth committing gets merged anyways so you still get the "Revert X" commit in there too.

Re: Fortunately, I don't squash my commits

#317

Post by saagarjha »

maccard wrote: post #262
saagarjha wrote: post #216

Earlier quoted context omitted.

That just sounds like a bad squash.

If the original commits are: - Change X to 10 by Foo - Change X to 100 by Bar - Change X to 50 by Baz And that gets squashed into `Change X to 50 by Baz`, you lose the context as to why Foo and Bar changed it, and the values. If I need to go investigate an issue with X, I'd rather thave the history of all the changes.

Commits by multiple people should rarely, if ever, be squashed.

Re: Fortunately, I don't squash my commits

#318

Post by saagarjha »

grumple wrote: post #290
saagarjha wrote: post #211

Earlier quoted context omitted.

Then you split the feature up? It’s generally possible to do this.

I mean, I’m the one arguing for smaller commits, so yes, if you make it 10 commits via 10 prs instead, that’s fine with me. But if all of that has to go out at the same time, that’s not any different than one pr with 10 commits (and probably worse because it’s harder to see all the changes together).

I actually occasionally make those kinds of pull requests and would recommend that over the alternative.

Re: Fortunately, I don't squash my commits

#319

Post by acdha »

nimblegorilla wrote: post #313
acdha wrote: post #284

Earlier quoted context omitted.

It's not a good look to trash someone's career because they made a mistake. This happens to everyone everywhere — the only question is how well you handle it.

Point is that `squash` is a useful tool used by many other successful professionals. I'm allowed to disagree with the author's opinion of the root cause of his bug and the factors that made it hard or easy to debug.

Nobody is saying you can’t disagree. My point was just that you should focus on the topic rather than attacking someone you aren’t familiar with. Doing so was a distraction which didn’t make your argument stronger.

Re: Fortunately, I don't squash my commits

#320

Post by FeepingCreature »

Nursie wrote: post #271
FeepingCreature wrote: post #14

Earlier quoted context omitted.

I squash commits. Well, I rebase so that changes are logical rather than historical. This is because when people read the commit history, which actually happens regularly, they would actually like a complete story, not 15 commits of "fix audit", "fix review" and "fix typo" - let alone refactors where previous work in the PR is thrown out, which you can by definition never care about. Commits so small that they're non…

When I read the commit history I want to see what was committed. "Hmm, I had a half working X509 chain resolver there that turned out to be unnecessary at the time but would save me a day's work now..."

Keep it on a local branch?
Post reply on HN