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

241–250 of 333 posts

Re: Fortunately, I don't squash my commits

#241

Post by MaxBarraclough »

pierrebai wrote: post #222
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.

Perhaps we could 'have it all' if git introduced a way of bundling commits, a bit like code-folding in an IDE. The bundles could be expanded when you need fine-grain detail of development history, but by default would be unexpanded and would behave like a single big commit, avoiding the issue of always seeing overwhelming detail.

Re: Fortunately, I don't squash my commits

#242

Post by dclusin »

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.

I think it stems from the lack of experience with actually having to backport/revert non-trivial code changes in a large repository used by many people. For most engineers version control is just seen as a mechanism to collect credit for ones work. It's only when you get into these thorny situations do you appreciate the power of git.

Re: Fortunately, I don't squash my commits

#243

Post by WorldMaker »

dcolkitt wrote: post #178
davewritescode wrote: post #45

The reason to squash commits is more than just keeping your commit history read-able, it's about making easy to revert a feature and being able to keep history in a way that makes it simple to revert a change if you run into issues. If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue. If I had spread that endpoint across 25 commits…

I wish git had a builtin notion of two different types of commits: working commits and release commits. I really like making tiny, continuous commits as I work. It's a great flow. git-revert becomes a Ctrl-Z on steroids. I don't what to clutter up the "official" history, with all these tiny changes, many of which don't even compile. That breaks git-bissect and all kinds of other flows. So the only option is to squash…

You can use merge commits to create your release groups. Use tools like --first-parent to limit the depth you see of the graph by default; that clutter can still be there, but you can take advantage of the nature of the graph itself to "declutter" simply by setting the "depth" you are working in.

Re: Fortunately, I don't squash my commits

#244

Post by derenge »

im3w1l wrote: post #235
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…

It's not fun if you rebase, and realize that every single one of your many commits need to hand-merged.

Agreed, I used to interactively rebase but have since switched to a four step process. If you have conflicts, you'll deal with them all at once when you merge in `origin/master`.

  git fetch

  git merge origin/master

  git reset origin/master

  git commit

Re: Fortunately, I don't squash my commits

#245

Post by WorldMaker »

saagarjha wrote: post #201
m12k wrote: post #77

Earlier quoted context omitted.

> If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue I'm firmly of the belief that any benefits that squashing brings would be better achieved with better tooling, rather than by re-writing history and throwing away potential debugging information. In this case, what you need is for git to make it easier to revert 25 commits in on…

How about the case where I made a commit because I wanted to switch to my laptop and continue working? Why should I keep that around ok my history?

It was clearly a natural stopping point in that you stopped working on the code for the amount of time it took to switch. There's nothing wrong with encoding natural stopping points in your commit history, even when those natural stopping points don't always align with semantic stopping points (features/fixes/completed tasks). Sometimes those natural stopping points even encode data you might miss later: sometimes in making that switch you also mentally switch tracks and looking at where you stopped and where you restarted sometimes can remind you of things you forgot in between. I've found debugging cases where that helped me solve problems. (That said, in practice I rarely keep such "natural stop commits" myself, but I've also never been strict about it and sometimes keep them. There's nothing wrong with them and sometimes they are useful "waterline" markers in a larger effort.)

Re: Fortunately, I don't squash my commits

#246

Post by jkubicek »

SassyGrapefruit wrote: post #239

>I've always disliked Git's squash feature, and here's one of the many reasons to dislike it. Had this happened in a code base with a 'nice history' (as the squash proponents like to present it), that small commit would have been bundled with various other commits. This question always boils down to this metric. Which happen more often... 1. A circumstance arises where the dynamics of fine grained commits make the pr…

Having fine-grained commits and having a clean git history aren't mutually exclusive. If you create and submit small PRs and git-squash those PRs into the main branch, you'll get the best of both worlds.

FWIW, the way I use git results in me committing a lot. I treat it as, essentially a save point that I can undo to if I need to. The history for my personal branches is a mess of broken tests and false-starts on code paths that just aren't going to work. Useless for anyone but me (but fantastic for giving me an hour-by-hour breakdown of what I've been working on and what attempts I've made).

Re: Fortunately, I don't squash my commits

#247

Post by saagarjha »

WorldMaker wrote: post #245
saagarjha wrote: post #201

Earlier quoted context omitted.

How about the case where I made a commit because I wanted to switch to my laptop and continue working? Why should I keep that around ok my history?

It was clearly a natural stopping point in that you stopped working on the code for the amount of time it took to switch. There's nothing wrong with encoding natural stopping points in your commit history, even when those natural stopping points don't always align with semantic stopping points (features/fixes/completed tasks). Sometimes those natural stopping points even encode data you might miss later: sometimes in…

I don't make these commits often either, they exist almost exclusively to move code across machines. Actually, I commit much less frequently than most people, keeping most of my work in the staging area for long periods of time until it's ready to be committed. Probably a bad strategy, but it keeps my code clean…

Re: Fortunately, I don't squash my commits

#248

Post by bradstewart »

WorldMaker wrote: post #232
Pxtl wrote: post #110

Earlier quoted context omitted.

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. Merge commits work fine for most of that, you just have to adapt to merge UX/commands: --first-parent (to git log, git annotate, etc) gives you clean history viewing of just your "groups" (your merge commits). --first-parent even…

This. I hated working with merge commits until I discovered --first-parent. I'm not sure how it evaded my attention for so long.

Re: Fortunately, I don't squash my commits

#249

Post by WorldMaker »

twic wrote: post #48
np_tedious wrote: post #27

Earlier quoted context omitted.

The argument for squashing is that minor updates like spelling, renaming, or test fixes during initial development can really clutter the history if they each have a commit. Many would rather see the actual change "Update X to use Y instead of Z" in the history, and minor details like "Fix mock in XTestCase" or "Perform renames from code review" within that single commit. I'm sort of agnostic on this issue, but I do…

For me, it's the other way round: minor updates like spelling, renaming, or test fixes during initial development can really clutter the major updates. If i am making a commit that makes a complex but important change to some significant application logic, i want that commit to contain that change and only that change , so that when i have to re-read it a year later, it's completely obvious what i did and why. Bundli…

There is a special kind of commit that "just groups a previous run of commits", it is called a merge commit. Tools like --first-parent can restrict git log/git blame to just "top level" merge commits. The only real change is that isn't the default in most tools, but they don't have to show the full graph, they could better focus on a specific depth by default.

Re: Fortunately, I don't squash my commits

#250

Post by jdmoreira »

adrianN wrote: post #49
jdmoreira wrote: post #35

Earlier quoted context omitted.

I religiously squash my commits for each merged pull request. I seems like madness any other way to me... why have a bigger granularity than a single merge commit?

Granularity helps with bisecting issues.

at least in github after you find the squash commit equivalent to the PR you can restore the branch and bisect the rest in there. This is much faster!
Post reply on HN