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

Squash your commits

github.com

Post reply on HN
Print view View original

321–330 of 350 posts

Re: Squash your commits

#321

Post by blakeyrat »

blakeyrat wrote: post #92
MBlume wrote: post #26

If everyone on your team actually knows how to use git, much better to let them rebase their commits and mark out a series of clean, atomic commits which introduce the feature you're reviewing. If you have people who are incompetent at using git on your team, this feature will help protect your history from them.

Git's usability is a mess . I wouldn't judge anybody on their ability to use Git. Being subjected to Git at work makes me long for the days when I used Lotus Notes for email. Sure Lotus Notes is a usability disaster, but at least you get the sense they were trying to make things work. And, to be fair, it got slightly better each version. Using Git makes you feel like it was developed by people who simply hate you and…

And once again, giving my opinion on Git apparently is worthy of downvotes on this site. Make sure you don't go against the groupthink, folks.

Re: Squash your commits

#322

Post by abalashov »

cortesoft wrote: post #210
abalashov wrote: post #196

Call me naive, but wouldn't this problem be best solved by requiring that commits represent meaningful and working increments of work? I use 'git add -p' judiciously and only commit when having reached a point where something can be usefully said to be in some way "done". Sure, it's not perfect, and occasionally I end up having to do some cleanup of miscellaneous printf statements, debug values or typoes in subsequen…

Waiting until you have something useful has other drawbacks. For example, it might take many hours or days to get to a 'useful' and 'done' state - I don't want to go hours or days without saving my work in a manner that is easy to retrieve if something goes wrong. Besides the obvious 'hard drive failure' or 'laptop stolen' situations, there are also more frequent situations where 'oh shit, I went down a totally wrong…

Very good points. I guess I've just been too lazy to learn advanced rebasing / commit aggregation. Maybe I should, so I can more effectively take advantage of the upside while not polluting my commit history with intermediate crap.

Re: Squash your commits

#323

Post by forrestthewoods »

exDM69 wrote: post #288
forrestthewoods wrote: post #283

Earlier quoted context omitted.

I can teach an artist or designer everything they need to know about Perforce in 5 minutes. I can spend a year helping and they still won't be comfortable with Git. Every studio needs a Git expert to help people when they have a Gitastrophe. Perhaps your issue here is that P4 is too simple. You check a file in and it's there forever. Sync latest, change things, check in, voila! Once in P4 there is literally nothing y…

The point about artists I totally get. Git isn't designed for that. But similarly I'll argue that Perforce isn't designed for programmers, or at least a group of programmers spread far and wide (geographically and/or otherwise). I'm sure even p4 works great if you're quite close to the people you share the depot with. From my point of view, Perforce is designed from completely the wrong standpoint. The "big dump of f…

That's a fair assessment. Git and Perforce are designed for very different things. For video games, and especially non-coders, Perforce is clearly better imo. Git is made for very wide, open source projects. Private software projects fall somewhere in between. Some projects may skew one way or the other.

I'm fascinated by your use case because for my professional work I've never created or shared a patch. I just submit the new code and that's it. Possibly to some branch. More than likely straight to main. Merging heavy branches sucks. Even in Git.

But I definitely understand where you're coming from here. There's a heavy learning curve moving from SVN to Git. It's just a radically different way of thinking. You have to break your brain and reshape it. Moving from Git to non-Git is much the same.

When I worked on a Unreal Engine 3 game we often talked about doing things the Unreal way. The Unreal way sucked. It was stupid. Objectively wrong even. However it was important to do many things the Unreal way. Because if you did it your way that would only cause pain and suffering down the road. Because if you change a few bits to be your way then eventually they'll try to interact with bits that do things the Unreal way and it's bad times. So you grit your teeth and do it the Unreal way. If you use Git you gotta do it the Git way. If you use Perforce you gotta use it the Perforce way. As painful as it may be.

Re: Squash your commits

#324

Post by chris_wot »

hinkley wrote: post #309
chris_wot wrote: post #290

Earlier quoted context omitted.

Except it's not lying. If the unit of work is good, then watching the developer go backwards and forwards and making mistakes that stop the software from even compiling isn't even helpful - in fact, you can sometimes get multiple of these errors stack up in a row. Trying to bisect, even with bisect skip, is painful in these cases, and it doesn't even help with code reading. The general rules of Linus Torvalds are the…

I said elsewhere that the only use of squash that I strongly agree with is to remove bugs and other dumb mistakes. What I disagree with strenuously, to the point of anger, is having a code as where every line of blame tells me only who made a change and what feature it was for. And I know too many people who think of every feature or pull request as a single commit. THAT is lying, and I mean that in the judgement-pas…

Ah, yeah - I agree with that last bit about formatting changes - even if I have probably unintentionally violated that in the past.

However, if you have changed users > 1 to users >= 1 and there is some sort of intrisic logic to it, surely a. you put that reasoning into the commit message, and b. you add a comment into the code briefly explaining the significance?

I don't know about you, but I'd prefer to know about why this is significant within the code, rather than have to dig through the blame logs of a version control system!

Re: Squash your commits

#325

Post by chris_wot »

phire wrote: post #273
Pyxl101 wrote: post #228

Earlier quoted context omitted.

> Everything else should be recorded in the history. Forensics are important to the long term health of your project and you impoverish yourselves by scrubbing the crime scene. OK. So would you support an IDE that generated one individual commit per keypress? When I type "hello", that's five individual commits each changing a single letter. That is the true history of what happened, and it's typically recorded in you…

I actually implemented an eclipse plugin which recorded every keypress (among other things) for my 3rd year project at uni.

That's pretty interesting... did you ever publish this code?

Re: Squash your commits

#326

Post by MaulingMonkey »

chris_wot wrote: post #289
MaulingMonkey wrote: post #272

Earlier quoted context omitted.

How about I just look at the latest ~33h directly on that page ;) I like the scope of a lot of those commits, although a few are still chunkier looking than I'd like - take that with a grain of salt, though, as I don't have a good enough feel for the codebase to reasonably estimate how much more they could be chunked up. Pretty much everything has a review link, which is nice. I'd expect more back and forth in the co…

Ah... sberg's one commit message that could be more descriptive :-) That NSS commit has two very experienced reviewers, but fair point! wrt screenshot linking, I guess a link to the LibreOffice bugzilla would be nice. Thanks for the info, that's really quite insightful. Appreciate you taking the time to give it!

> That NSS commit has two very experienced reviewers,

I must be blind - somehow I only saw one the first time around, but they're clearly both there.

> Thanks for the info, that's really quite insightful. Appreciate you taking the time to give it!

I'll take your word for it ;). And no problem.

Re: Squash your commits

#327

Post by teacup50 »

cwilkes wrote: post #229
teacup50 wrote: post #192

Earlier quoted context omitted.

Have you tried making sense of a project 10 years old? 20? 40? I can "experientially" state that squash throws away very necessary information for anyone trying to make sense of old code.

that's more of how squash was applied in the situation ... If they had huge commits then while squash might break it up a bit that's a problem with how the people did their work. Myself I like to do PR and merges with code that can be logically comprehended quickly and doesnt break the build. a lot of that is due to being emphatic to people that are doing the reviewing. I know they don't know the context as they aren…

It's rare that the contemporary author knows what will be useful context in two decades.

Re: Squash your commits

#328

Post by chris_wot »

MaulingMonkey wrote: post #326
chris_wot wrote: post #289

Earlier quoted context omitted.

Ah... sberg's one commit message that could be more descriptive :-) That NSS commit has two very experienced reviewers, but fair point! wrt screenshot linking, I guess a link to the LibreOffice bugzilla would be nice. Thanks for the info, that's really quite insightful. Appreciate you taking the time to give it!

> That NSS commit has two very experienced reviewers, I must be blind - somehow I only saw one the first time around, but they're clearly both there. > Thanks for the info, that's really quite insightful. Appreciate you taking the time to give it! I'll take your word for it ;). And no problem.

I'd love to see a system that can show reviewers as metadata within git itself.

Re: Squash your commits

#329

Post by teacup50 »

scrollaway wrote: post #306
teacup50 wrote: post #184

Earlier quoted context omitted.

It's inherently deceptive. Instead of thinking through problems to produce their solutions in an ordered, clear fashion, they make a big spaghetti mess, and then hide the sausage-making in a squashed commit that throws away work that may in fact, be very useful later on, all to present the illusion that they arrived at the visible conclusion without misstep. That's deceptive, wasteful, and has more to do with ego or…

The kind of work you're thinking of is generally what you put in comments. Someone reading the code will not be reading the commit log. If there's gotchas in the code, they should be expressed in comments, not in the commit log. The commit log, on the other hand, should always be readable for devs, especially newcomers to the project, to get an idea of how to develop small and concise features and how to contribute.…

What you're missing is that "gotchas in the code" are not always known when the code is being written.

Very often, you have to piece together what happened and why from the record of what people actually did.

There's no such thing as "personal history" with the code in the context of SCM commits. It's all project history.

This new idea is both deceptive, and honestly, shocking. No SCM system previously has ever been used to actively encourage discarding history, and decades of using these SCM systems ought to have adequately demonstrated why that history matters.

Re: Squash your commits

#330

Post by lerpa »

MaulingMonkey wrote: post #255
Pyxl101 wrote: post #228

Earlier quoted context omitted.

> Everything else should be recorded in the history. Forensics are important to the long term health of your project and you impoverish yourselves by scrubbing the crime scene. OK. So would you support an IDE that generated one individual commit per keypress? When I type "hello", that's five individual commits each changing a single letter. That is the true history of what happened, and it's typically recorded in you…

> OK. So would you support an IDE that generated one individual commit per keypress? When I type "hello", that's five individual commits each changing a single letter. Not OP but - conceptually? Yes. I've written file formats which preserve undo/redo history, for example. The caveats: 1) I don't want to inadvertently leak my password. This is an issue with things such as local bash command history buffers as well, an…

> My tooling needs to be built around a different level of granularity as the default. I'm not OK with single letter commits cluttering up my git log, for example. Having them around to drill down into if I need them? Sure.

And that would be nice to have, a vcs that allows you to fold and unfold commits to different levels of granularity.

Wanna have only a straight line history with all feature branches squashed? There you have it. Just need some of them like that? Sure enough. What if you want every time the file was saved? Not a problem, just configure it to commit automatically.

Post reply on HN