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

Fortunately, I don't squash my commits

blog.ploeh.dk

Post reply on HN
Print view View original

221–230 of 333 posts

Re: Fortunately, I don't squash my commits

#221

Post by apta »

ZephyrBlu wrote: post #36
NateEag wrote: post #28

Earlier quoted context omitted.

You have to go dig the branch out of the central repo, though, which is annoying and takes time. That was the price I was thinking of. You're certainly right that PRs and large commits are orthogonal.

Navigate to PR -> Restore Branch -> `git checkout ` How is this annoying or time consuming? It takes less effort than adding, committing and pushing changes.

Is it always possible to restore branches from the PR? e.g. do some code review systems automatically delete committed branches after a certain time period?

Re: Fortunately, I don't squash my commits

#222

Post by pierrebai »

Vinnl wrote: post #204

I usually understand "squash" to mean "bundle everything in a PR into a single commit". Which can indeed break bisect workflows. There's a middle ground though: rebase your commits, but not necessarily into a single one. Before I submit a PR, I rebase my branch (which has lots of small commits, some of which undo previous work or are a work-in-progress), and make sure that every commit is as small as it can be withou…

If you work on a very large projects with many released version and need to cherry-pick fixes to back-port, you'd be very, very, VERY glad that each branch got squashed.

The story told in the article mainly shows to keep your PR focused. You can squash as long as you don't do 2-week-long 37-commits branches.

Re: Fortunately, I don't squash my commits

#223

Post by mpawelski »

A lot of people seems to suggest that squashing PR's branches is better because you don't get commits that are broken and it doesn't work good with "git bisect".

But IMO it's not a big deal, you just do "git bisect skip" for these comments and at the end of bisecting session instead of one wrong commit you'll get couple of, for example one commits that builds and two that you skipped and doesn't build. It's very likely that looking only at this 3 commits will help you find the issue because they might be part of much bigger branch which would otherwise be squashed to one huge commit with enormous diff.

I much more prefer to require that PR's branches are always merged without fast forwarding. So there is always merge commit for PR. Then you can actually display list of this commit with "git log --first-parent" and they should always build because build server verifies it.

Unfortunately "--first-parent" doesn't work for "git bisect" now, but it finally will in the next git release! [1]

[1]https://github.com/git/git/blob/ab4691b67bc1a2cd8d9068fb03e3...

Re: Fortunately, I don't squash my commits

#224

Post by wcarss »

CrunchyTaco wrote: post #106
dastx wrote: post #86

Earlier quoted context omitted.

> squash merge into shared branches Why not just rely on a merge commit instead?

My gripe with merge commits is they don't integrate nicely with `git blame`. If I'm looking through historic commits (to understand why a change was made, or perhaps to debug an issue) I'll often `git blame` the line and diff that commit. If the commit is super granular, I can't get the context of the whole change: I need to dig for the merge commit then look at that, which is faff. If there's a way that I don't know…

That's an interesting point, but it seems like one among many very good arguments for "right-sized" or "logical" commits, i.e. not 10 similar-shaped bugfixes and also not one-line no-context diffs -- how big should the PR and merge commit be though? Maybe you put the 10 similar-shaped bugfixes together into one PR because they review together easily, but each fix is its own commit, because they all logically stand on their own.

Your use-case is actually the cause of a common rule I've seen at work of requiring a ticket reference in each commit message, which allows looking up the original ticket and associated PRs, along with any commentary & discussion at the time the commit was merged.

On a big code-archeological dig, I often follow a path like run blame -> look at the diff -> pull the ticket reference -> find ticket in issue tracker -> read its description & comments -> find linked PR #'s in the ticket tracker -> open PRs & read diffs and comments -> repeat for linked issues if needed (and then as often as not still end up baffled)

One team actually kept an old redmine VM instance running mostly based on my personal use long after we'd migrated to JIRA, so... I think my approach may be a little unusual! At the least, doing better sized commits would a huge step for every case involving blame.

Re: Fortunately, I don't squash my commits

#225

Post by takeda »

Pxtl wrote: post #110
alxmng wrote: post #55

Earlier quoted context omitted.

Programmers can have the best of both worlds. Use granular commits on a local branch and squash merge into shared branches. That way one gets clean shared history while preserving local work history.

The problem with this approach is the local branch is no longer represented in the shared branch. So if I'm working on a larger feature and want to PR an intermediate part and continue working, I'm in for a bad merge. If I want to merge my hotfix topic branch into both the release and the master branch, their commits won't match so I can't check if it's present in both automatically. If a topic branch is left up inst…

> I desperately wish git had a "group commits" feature that let me manage a cluster of related commits as a single commit for the purposes of history-viewing, reverting, and cherry-picking.

Isn't this what git does by default when you merge your changes? The merge commits group small commits together.

Re: Fortunately, I don't squash my commits

#226

Post by nikisweeting »

byte1918 wrote: post #105
m12k wrote: post #66

Earlier quoted context omitted.

What do you use your "cleaner history" for? I seldom go back and look at historical commits unless I'm debugging, in which case I'd prefer to know what actually happened at the time with as much information preserved as possible.

A clean history with proper commit names can work as a change log for you app. We actually did that and it worked quite well. In Azure DevOps the release pipelines have access to the list of commits since the previous release so one only has to simply take the titles of those commits to build it.

You can achieve that with PR titles instead of commit titles.

Re: Fortunately, I don't squash my commits

#227

Post by aayjaychan »

BeetleB wrote: post #194

Mercurial's evolve extension has fold , which is similar to squash . However, it still has all the individual commits if you wish to examine them - they're just "hidden" and the usual commands (logs, etc) will show just the squashed commit.

Git does hide the old commits as well. What git doesn't do is track which commits are replaced by which. So sharing mutable history and seeing how a commit evolved over time requires more heuristic than necessary.

Re: Fortunately, I don't squash my commits

#228

Post by wcarss »

corytheboyd wrote: post #217
Vinnl wrote: post #204

I usually understand "squash" to mean "bundle everything in a PR into a single commit". Which can indeed break bisect workflows. There's a middle ground though: rebase your commits, but not necessarily into a single one. Before I submit a PR, I rebase my branch (which has lots of small commits, some of which undo previous work or are a work-in-progress), and make sure that every commit is as small as it can be withou…

I wish more people would naturally come to this conclusion in their careers, but many people I have worked with just don’t care about maturing their git disciplines. All it takes is one teammate who thinks it’s a waste of time to undo the progress of everyone else. For context, my career has been in web development start ups, which generally reward the cavalier and tolerate the careful.

It's interesting that you note it only takes one person to undo the progress -- by the reverse token, every person who works in this way adds value to the practice and the history, which is why (and how) I've advocated for and to individuals to spend time on it.

Any one person can muddy the history up (by ruining bisect, say), but any one person can also improve it (by leaving good notes and right-sized commits whenever possible).

Re: Fortunately, I don't squash my commits

#229

Post by vonmoltke »

Joker_vD wrote: post #2

Do people out there actually squash commits? Granted, I didn't change many work places in my career, but at no place where I worked people squashed commits. What's even the point of it? It's not like people routinely read the commit history, and when they do, they really would like a complete story, not 20 gargantuan commits that contain 3 years of development.

It really depends on where you work and how your company's repo is organized. For instance, where I work 20 squash commits would represent, at most, 10 minutes worth of commits to the monorepo. Not squashing on merge would quickly turn thousands of daily commits into tens of thousands. It's already impractical to find suspect commits via git, and we typically use our code review tool to find the change that broke something (and that change includes the developer's full branch history). Adding more commits would needlessly slow down the tooling that displays 'git blame' results (and likely other commands).

I suspect there is a pattern in the comments here. People who work on small teams with granular repos that, individually, don't see a lot of daily activity think squashing is bad and erases valuable history. People who work with large repos that see high commit velocity (like a monorepo) think squashing (at least merge squashing) is beneficial and don't see the loss of information as problematic because it's hard to access it in the first place. Maybe I'm just projecting my own opinions on this; I'd like to hear perspectives that conflict with my assumptions.

Re: Fortunately, I don't squash my commits

#230

Post by sixstringtheory »

takeda wrote: post #214
Vinnl wrote: post #204

I usually understand "squash" to mean "bundle everything in a PR into a single commit". Which can indeed break bisect workflows. There's a middle ground though: rebase your commits, but not necessarily into a single one. Before I submit a PR, I rebase my branch (which has lots of small commits, some of which undo previous work or are a work-in-progress), and make sure that every commit is as small as it can be withou…

Same here, I especially love `git rebase -i ` it opens an editor and I have an option to edit specific commits, reword the commit, squash multiple commits together (don't use this one often) or do fixup (which basically merges commit to the previous one)

If you haven’t yet, check out rebase’s --autosquash option, along with git commit --fixup or the commit message directives “fixup!” and “squash!”
Post reply on HN