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

91–100 of 350 posts

Re: Squash your commits

#91

Post by WorldMaker »

zenlikethat wrote: post #75
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.…

They're not full of little lies. Projects insist on squash-before-merge to help developers keep their sanity. Imagine working on a fast-changing block of code with 20 or so other people concurrently. If all 20 of those peoples have patches submitted to master for review, and all of those patches have multiple commits each, then every time one gets merged, the others will have to rebase to its changes and fix conflict…

«the others will have to rebase to its changes and fix conflicts for _every single commit_ while the fast forward plays out»

I'm mostly sort of advocating a "rebase none of the things" approach. Fix conflicts only when they happen in a branch (the GitHub PR system very nicely doesn't let you merge branches that conflict with your target branch and with CI information even better it won't let you merge branches that don't build). It's really not a bad experience.

Re: Squash your commits

#92

Post by blakeyrat »

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 want to see you fail.

Re: Squash your commits

#93

Post by eblanshey »

Usually when squashing branches locally, all the changes are set to myself as the author, effectively losing history of who did what in the feature branch. How does Github handle this?

Additionally, the lack of the commit history for that branch often caused merged conflicts when merging the same branch again (if it had additional new fixes, for example). That's why I switched to using git merge --no-ff.

If it were very easy to do, I would definitely do a git squash, as it keeps history very clean. I just don't want to have the problems listed above.

Re: Squash your commits

#94

Post by scrollaway »

dasil003 wrote: post #82
scrollaway wrote: post #56

Earlier quoted context omitted.

Right, sometimes . Pull requests are not necessarily a "unit of change" like you mentioned, though. For example, the first link I gave should not be squashed. But I don't want it to create a merge commit either. I'm a little underwhelmed with the feature, it looks like it's either "squash everything" or "make a merge commit". There's no option to rebase & merge and/or selectively squash.

Exactly. In order for always-squash to work, then every PR must be the smallest possible atomic change. But often times certain features don't degrade to nice small atomic changes. It's sometimes useful to see that as a development process smell and consider using feature flags and other things to incrementalize the development, but sometimes the cleanest thing to do is just have a series of commits. I don't see a go…

Interesting. It's the first time I hear a fairly solid argument in favour of --no-ff. My main argument against it is keeping a clean commit log on github itself (and the default git log), as it's an entry point for new contributors.

Example:

https://github.com/lxde/pcmanfm-qt/commits/master

vs

https://github.com/facebook/react/commits/master

Re: Squash your commits

#95

Post by dang »

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.

This comment breaks the HN guidelines by calling names, and unfortunately a number of your other comments have done this as well. Please post civilly and substantively or not at all.

https://news.ycombinator.com/newsguidelines.html

Re: Squash your commits

#96

Post by WorldMaker »

geuis wrote: post #88
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.…

Couldn't disagree more. Having worked extensively on teams on both sides of this issue, I can experientially state that a well-done git rebase and commit strategy is much more useful and helpful. In terms of feature branches: The individual engineer is free to do individual commits in their branch as they need to in order to keep track of their work. Before they submit a pull request, they should rebase and squash al…

I'm only arguing that what you see as clutter, I see as potentially interesting history, and a mess of merges and reverts are more interesting than people give them credit. It can tell you quite a lot about a project. (Did you learn from reverting 'Merged: Did This' anything about why it shouldn't have been merged? Did you miss something in 'Merged: Did that' that didn't quite merge easily? That's easier to find/diagnose with smaller more often merges than big evil merges...)

Anyway, to each their own, and I appreciate your preferences differ from mine.

Re: Squash your commits

#97

Post by jasode »

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

>Seeing how the sausage was actually made, ... it is meaningful and will tell you a great deal about a project and its developers... I trust that.

...tidy commits are aberrations and full of little lies...

...small, harmless lies.

Interesting choice of words.

Here's another way to think about squashing private commits for public consumption: programmers do not install keyloggers and upload their entire keystroke history including every Backspace and Ctrl+Z used in their text editor to the repositories. And, most of us wouldn't care about seeing it.

Whether John typed "x = 218^H^H73" or "x = 273" is a meaningless distinction and irrelevant noise. Those spurious ^H Backspaces are equivalent to the twitchy multiple commits in private branches. We really don't want to see them. Think of private noisy commits as an extended workspace of a text editor. If squashing those commits is a lie, the Backspace key without an audited keystroke log is also a lie.

Side note: The other comment downthread about keeping all private commit history for "git bisect" is a red herring. Sometimes a commit will deliberately have broken syntax -- e.g. make a quick commit before getting up to grab a soda -- it won't be CI test worthy. Besides, an automated CI server's cpu cycles can point to an upstream integration/test/qa branch instead of a programmer's private branch.

Re: Squash your commits

#98

Post by natrius »

scrollaway wrote: post #56
natrius wrote: post #53

Earlier quoted context omitted.

To clarify, pull requests shouldn't be squashed before review. They should be squashed when they get merged in, like this GitHub feature does. The granular commit history is useful during code review. It is not useful as a future developer trying to evaluate how the behavior of the program changed over time.

Right, sometimes . Pull requests are not necessarily a "unit of change" like you mentioned, though. For example, the first link I gave should not be squashed. But I don't want it to create a merge commit either. I'm a little underwhelmed with the feature, it looks like it's either "squash everything" or "make a merge commit". There's no option to rebase & merge and/or selectively squash.

I think your first link should be squashed once the code has been reviewed. When looking back on history, commits are most useful when they're a list of behavior changes in the software. That pull request "exports meshes as OBJ." That's what's useful for future developers, not "add Transform fields." Leaving those in your history makes it harder to work with, not easier. If someone cares about the back and forth that happened within that behavior change, the pull request is always available.

Re: Squash your commits

#99

Post by jecjec »

dang wrote: post #95
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.

This comment breaks the HN guidelines by calling names, and unfortunately a number of your other comments have done this as well. Please post civilly and substantively or not at all. https://news.ycombinator.com/newsguidelines.html

Thanks dang.

Re: Squash your commits

#100

Post by kylnew »

WorldMaker wrote: post #77
kylnew wrote: post #67

Earlier quoted context omitted.

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

«Have you ever tried following a change in a repo that came from an unsquashed PR?» I have a self-congratulating black belt in source code archeology. With the right tools, most of which are on GitHub, even, such as good commit range diffing, smart uses of tags and branches, and knowing how to navigate the DAG from merge commits (more reason to -no-ff) you have a lot of power in your hands. «What's truly meaningful I…

I think this really comes down to team. It's kind of an all-in or nothing thing and if you go against the grain everyone will just end up angry
Post reply on HN