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

101–110 of 350 posts

Re: Squash your commits

#101

Post by glhaynes »

pkamb wrote: post #86
glhaynes wrote: post #33

Earlier quoted context omitted.

It seems like it'd be nice to have two levels of granularity exposed in views of a source control system's history, basically corresponding to pull requests and commits. So you could drill-down to individual commits as needed, but would normally be able to work at the PR level.

That's the `diff` tab on the PR

But the PR isn't retained (afaik) in the repo's history as a distinct entity (I'm talking about git proper here, not extra tools like GitHub, etc). In the end, git just has commits. [Edit: as prodigal_erik points out, perhaps merge commits are really what I need to be looking at.]

Re: Squash your commits

#102

Post by natrius »

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…

Try it both ways. I used to agree with you until I tried squashing after code review.

Re: Squash your commits

#103

Post by Stratoscope »

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

> It's real and visceral and how software is actually made...

It's also extraordinarily cluttered, and it really gets in the way when someone later want to do a 'git bisect' to track down when a bug was introduced.

When I'm working I do frequent little commits just to capture and back up my broken stream-of-thought experiments. None of those are going to be relevant to people who work with this code in the future; how does it benefit them to impose my haphazard process on them?

Of course if there's a way to break up my final commit into more meaningful smaller commits, I do that rather than one monolithic commit.

For example if I clean up some whitespace issues, add some new comments to old code, and implement a new feature, I'll put those in three separate commits even if I originally did the entire change at once. In this case you'll see more commits in the public history than I originally had.

Or if I check in a new version of some external library, add an API call that uses it along with its tests, and add UI code that calls the API, those may be separate commits in that order.

My goal is to make the public history useful to future developers.

Re: Squash your commits

#104

Post by scrollaway »

natrius wrote: post #98
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.

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…

"Add transform fields" may not be a very descriptive commit message, but those fields are fully independent from the OBJ exporter. They are the implementation of unity's Transform class. This implementation was stubbed before, it happens to be needed for an OBJ exporter to go through, but has nothing to do with the exporter itself.

Re: Squash your commits

#105

Post by falsedan »

ams6110 wrote: post #41
falsedan wrote: post #28

Earlier quoted context omitted.

Fucking around with anything will do that. Learning and understanding a new tool & using it where it's appropriate will save you time and effort!

The problem is, are we developers or source code librarians? My git workflow is pull, commit, push. I don't rebase or branch or anything else because it completely distracts me from what I'm doing as a developer. YMMV.

  > The problem is, are we developers or source code librarians?
I don't understand the connection, developers can use tools which require learning/training and are free to not use those tools?

Re: Squash your commits

#106

Post by glhaynes »

prodigal_erik wrote: post #43
glhaynes wrote: post #33

Earlier quoted context omitted.

It seems like it'd be nice to have two levels of granularity exposed in views of a source control system's history, basically corresponding to pull requests and commits. So you could drill-down to individual commits as needed, but would normally be able to work at the PR level.

Does "git log --merges" get us there?

I suppose it does, though at least the tool my org uses doesn't write good descriptions on the merge commits that are created upon merging in a PR — they're just like "Merge pull request 190 from …" when I'd prefer it to be named for the changes that are actually in that PR. That's good to know that exists, it could be useful. Thanks.

Re: Squash your commits

#107

Post by andrewprock »

WorldMaker wrote: post #96
geuis wrote: post #88

Earlier quoted context omitted.

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

Here, that something might be "potentially interesting" is not worth the cost. In fact, it's probably a net drain on the organization.

I once had a manager revert code formatting because he was "potentially interested" in having svn blame always show who wrote the actual code. In the meantime, it cost more time to develop because the code was impossible to read.

When "potentially interesting" begins to impede productivity, the value of that policy needs to be established. Do you really want to incur development time cost (something that is always ongoing) just to make the code archaeology (something that does not need to happen very often) a little bit easier?

Re: Squash your commits

#108

Post by rimantas »

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

Yes it tells the story. Does it help to understand the history of the code? Not necessary. I care most about what, when and where came from, not some fiction around that.

Re: Squash your commits

#109

Post by InclinedPlane »

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

What annoys me is that so many people take the position that there's no other way to improve the experience except for building an hazardous and error prone system into the core workflow of a tool that should ideally deal primarily with immutable history, rather than building better tooling to manage that complexity and present history in a useful way other than a raw list of commits. I mean, who would build such tools, and isn't managing complexity hard? Oh wait, it turns out we're developers, and managing complexity is the core reason of existence of all software engineering. It's really rather silly.

But it's a lot easier to convince devs that using tools with bad UI elements is hardcore and makes them look smart instead of demanding improvements.

Re: Squash your commits

#110

Post by alanh »

spleeyah wrote: post #2

Unsure if April Fool's joke...

Confirmed as not a joke. (The change is subtle as you have to click the green Merge button before being presented with the ability to choose a merge type via a combo button/dropdown component.)
Post reply on HN