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

301–310 of 350 posts

Re: Squash your commits

#301

Post by dsmithatx »

hnrodey wrote: post #115
dsmithatx wrote: post #32

Earlier quoted context omitted.

As a git novice I wonder, doesn't a proper workflow do the same thing? When I submit a feature branch it might have a lot of ugly commits. However, once I merge it to an integration branch there is one nice commit explaining what I did. When coworkers create Pull requests I don't go through all of their commits and changes along the way. I just look at the diff so, I don't see the need for them to squash it first.

Once merged, the history of your feature branch becomes part of the history of the integration branch. Sounds like you're using GitHub (Enterprise) or something similar where the pull request view shows you all of the changes in a "squashed" fashion.

Yes Bitbucket so, maybe that explains it.

Re: Squash your commits

#302

Post by jondubois »

I think squashing commits makes sense if you're working in a big team and/or on a complex/large project - The main advantage of it is that it speeds up the QA process because it cleans up all the back-and-forth (exploratory) changes that tend to happen during development.

If you squash properly, each commit will represent a small standalone feature.

It does reduce your commit count though :(

Re: Squash your commits

#303

Post by dsmithatx »

overgard wrote: post #182
dsmithatx wrote: post #35

Earlier quoted context omitted.

Strange that everyone these days uses Git considering it's unusable.

Everyone is a bit of a stretch -- the OP might have been a bit insulting; but he has a point.. hacker news can be somewhat of an echo chamber, and I think people assume Git is (or should be) a lot more widespread than it actually is. A lot of large companies still use perforce for large repository support, a lot of people still use subversion because it's simpler and they don't need a DVCS, etc. Having been the "git…

Well having managed 1000+ clients a few jobs ago, I can tell you the majority of companies these days use Git. With the proper hooks and gitflow I never found I had to tell users much once the workflow was understood.

At my last job we had about 40 devs in India spread out in different cities. We re-wrote much of Android and our Git repos were massive. This meant devs needed a local repo and couldn't be expected to work with a remote other than commits. Only once with all these random developers did history become a mess and we had to rebase and clean things up. I think a lot of people fail to understand how to implement Git properly and are making it overly complicated for daily use.

Re: Squash your commits

#304

Post by Gmo »

WorldMaker wrote: post #59

Sometimes I feel like it's a minority position, but I think it strange all the efforts people go to in order to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list. Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that.…

You're not alone man, but I feel that we are indeed in the minority ...

It looks like it comes down to the style of the dev/team, because I NEVER do any kind of WIP commit.

Re: Squash your commits

#305

Post by dboreham »

As this thread approaches 300 posts I'm wondering when we're going to get out of this Git Tarpit we've somehow got ourselves into?

To be charitable: Git seems to be a good tool designed for Problem A, being widely used for Problems B,C,D for which it is a fairly poor choice.

I _think_ we got here through some mix of "but it's really fast!"; "I can do _anything_!!"; "But Linus says its great!"; "I don't need to pay for a beefy server any more!"; "New _must_ be good, right?".

In any event, how do we get out the ditch and back to work making software vs. trying to reason about the unreasonable? I personally, for the kind of projects I'm involved with (small teams, all paid by the same piper, with aligned clear goals and competent coders), had perfectly satisfactory revision control systems since around 2000 (except when required by employer to use Clearcase..). It would be nice to get back to that future.

Re: Squash your commits

#306

Post by scrollaway »

teacup50 wrote: post #184
jessedhillon wrote: post #179

Earlier quoted context omitted.

> you trying to push this conversation towards it's extreme, absurd ends I would remind you that you are the one introducing morally charged terms like "lying" when describing rebasing. The fact that you cannot conceded even that those who disagree with you are at least morally good actors is the source of the extremism in this conversation. I would encourage you to seek hard to understand how it could be that morall…

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. Smaller, cleaner and always-buildable commits also make for very easy git bisects.

Git isn't here to record your personal history with the code, it's here to provide developers with an understanding of how the project evolved. It's not deceptive to arrange your commits to make them clean, it's part of creating a clear, understandable, easily-reviewed unit of change.

Re: Squash your commits

#307

Post by chmaynard »

devit wrote: post #66

The key principle is that the software should always correctly work at any point in the chain of commits, so you must squash commits that are "oops, fix X in previous commit". Once that is satisfied, commits should be as small as possible, so that information about the grouping of changes is preserved.

This advice seems very sensible. Thanks for adding some valuable ideas to the discussion. I'm now reading the git documentation on re-writing history:

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

Re: Squash your commits

#308

Post by sulam »

chris_wot wrote: post #260
phasmantistes wrote: post #160

Earlier quoted context omitted.

Yep, in chromium-land we do something similar: You can upload multiple different versions of a single code review, and reviewers can diff both against the base and against previous versions of the review. This is helpful for showing "stories", responses to comments, and for "my original commit got reverted, so here I've reuploaded it, and then also uploaded the fix, so you can clearly see what's different this time".

Is that using gerrit?

Rietveld looks like. Which used to be the code review tool at Google, but has since been replaced. Not by Gerrit. ;)

Re: Squash your commits

#309

Post by hinkley »

chris_wot wrote: post #290
hinkley wrote: post #185

Earlier quoted context omitted.

Not all lying makes you a bad person (thank you so much for the gift! I love it!). But it's still lying.

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-passing definition of the word. You're fucking up the version history intentionally, and you should be stopped.

I'm not in the habit of reading code for fun. I have a job to do, and I want to do it. If I'm looking at the version history it's pretty much only for two reasons. Maybe I know for a fact there was a clever bit of code in this file and it's gone now, so I need to find it. Was it deleted or did you split isn't off into another file? I like those but they don't happen to me very often.

More often I'm reading blame because of a wtf moment. I can't think of a logical reason why the code looks the way it does, but I need to make a change and so I need to know if the person who wrote it was trying to do accomplish something or just confused.

Commit a8bcdef by dingus Implement feature #532

That tells me what changed, who changed it, how it changed and when, but I've lost the why. I know, you probably think "feature 532 is why, duh" but it doesn't tell the story of the intermediate states and why for instance they changed 'users > 1' to 'users >= 1'.

And if there is one class of commit should absolutely and under no circumstances ever ever be squashed it's any commit where you reformatted code. If a line changes and its part of a commit for a feature I'm going to assume that method body was all you, and stop looking. If you 'wrote' it but the commit message is "pretty print" I know I have to go pull a blame on the parent version to keep digging.

Re: Squash your commits

#310

Post by krisdol »

dsp1234 wrote: post #137
WorldMaker wrote: post #59

Sometimes I feel like it's a minority position, but I think it strange all the efforts people go to in order to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list. Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that.…

isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that. Here is a (made up), but generally realistic git log git log | grep -i WIP mon 5pm - WIP, going to work on this from home tue 4:45pm - WIP, going to work on this from home wed 2:30pm - WIP, meeting wed 5pm - WIP thu Noon - WIP, working from the cafe on my laptop fri 5pm - WIP, working from home sat 3p…

Tell whomever is naming those commits to stop. We don't squash or do PRs, but that is not at all a realistic history.
Post reply on HN