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

181–190 of 350 posts

Re: Squash your commits

#181

Post by hinkley »

sulam wrote: post #154
WorldMaker wrote: post #142

Earlier quoted context omitted.

I think it is hyperbole given the surrounding context of this article/thread is mostly speaking to squashing commits after a review has happened in a PR. I say that not as a judgment, I like hyperbole and admit my top-most comment was intentionally hyberbolic too. Hyberbole is a good conversation to have sometimes. A commit to git is a named snapshot of a file tree. That's it. All the other "worthiness" we ascribe to…

It's not destroyed, it's simply not on master. If you want to push that branch and have the history forever, that is an option.

Anything not stored on the system of record cannot be counted on to exist at any point in the future.

From a strategic standpoint, thinking of that data as anything other than 'destroyed' would be a grave error of judgement. From a retention standpoint the difference between 'could' and 'did' is profound.

Re: Squash your commits

#182

Post by overgard »

dsmithatx wrote: post #35
jecjec wrote: post #23

Git is actually unusable software. Fucking around with rebase WILL cause you more headaches than this is worth. The number of downvotes this has received tells me just how deluded the alleged community of software writers actually is.

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 guy" at a lot of places, I can definitely tell you that you can't just hand-wave away its usability problems, it definitely has a cost on peoples' time that other systems don't. (I rarely have to answer other peoples questions about P4, for instance)

Re: Squash your commits

#183

Post by nullc »

Annoying: you can't turn off both. If your project has a workflow where the webui merge should not be used (e.g. using signed merges) there is still no way to achieve that.

Re: Squash your commits

#184

Post by teacup50 »

jessedhillon wrote: post #179
WorldMaker wrote: post #123

Earlier quoted context omitted.

«If squashing those commits is a lie, the Backspace key without an audited keystroke log is also a lie.» In a world with infinite storage space and a good UX on top of it, I could absolutely see a case where it might be amazing to have a source control integration with the full undo stack of my editors. VCR roll through someone's efforts Twitch style and grab a box of popcorn as you drinking game your way through the…

> 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 shallow ideas about "cleanliness" than it does with usefully recording our work processes.

Re: Squash your commits

#185

Post by hinkley »

jessedhillon wrote: post #179
WorldMaker wrote: post #123

Earlier quoted context omitted.

«If squashing those commits is a lie, the Backspace key without an audited keystroke log is also a lie.» In a world with infinite storage space and a good UX on top of it, I could absolutely see a case where it might be amazing to have a source control integration with the full undo stack of my editors. VCR roll through someone's efforts Twitch style and grab a box of popcorn as you drinking game your way through the…

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

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

But it's still lying.

Re: Squash your commits

#186

Post by sethammons »

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

I'm not a big fan of clean history for the reasons you state. However, there is at least one big benefit of a clean history in the master branch: any commit can be checked out and assumed to have working code. This means you can use git bisect. Git bisect allows you to programmatically search through your commit history to identify when a certain behavioral change happened. If you have commits like "wip, not sure why the app wont start yet" in your master's history, you cannot leverage tooling like bisect. Let the sausage be created at the branch level, and keep master clean .

Re: Squash your commits

#187

Post by teacup50 »

kylnew wrote: post #67
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.…

Have you ever tried following a change in a repo that came from an unsquashed PR? It's hell. What's truly meaningful IMO is a git log that reads like a product change log

As someone who has spent a lot of time tracking down the origin of source code changes -- and the reasons for them, and the implications of the change -- by reviewing commit logs, I can think of little worse, short of no commit history at all, than trying to derive anything remotely useful from a commit history that has been condensed down to a product change log.

Even commits that lack good commit messages provide valuable information in the form of insight into the author's cumulative thinking/process.

Re: Squash your commits

#190

Post by teacup50 »

hashkb wrote: post #172
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.…

Squash isn't for linear history. That's the rebase vs merge-master-downstream debate. Squash is for getting your wip commits out of history, that kind of thing.

Many of us believe there's no such thing as a throw-away "WIP" commit, and if there is, the work should be better broken up and managed by the developer so that they're committing fully considered incremental progress.

The easiest time to catch a bug is when it's hiding in a 10 line diff, especially before you commit it.

It gets progressively more difficult as the scope of the changeset grows.

Post reply on HN