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

191–200 of 333 posts

Re: Fortunately, I don't squash my commits

#191

Post by mpweiher »

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…

> two different types of commits: working commits and release commits

??

   git tag
??

Re: Fortunately, I don't squash my commits

#192

Post by jefftk »

> 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 is a misunderstanding of what proponents of commit squashing advocate. Often, when working, you end up with multiple commits which represent a single change:

    remove debug logging and fix bug
    more logging
    debugging
    typo
Squashing these commits together into one coherent change makes for a history that is much easier to understand.

Squashing unrelated commits, however, doesn't help anyone.

(I prefer the --first-parent approach: https://web.archive.org/web/20180710234754/http://www.davidc...)

Re: Fortunately, I don't squash my commits

#193

Post by nicoburns »

bananaface wrote: post #183
nicoburns wrote: post #169

Earlier quoted context omitted.

> 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. I usually deal with this by `git rebase`ing your feature branch on top of the shared branch as soon as the PR is merged. You sometimes still get merge conflicts with this approach, but they're always in the code you've just written so they're usually pretty easy to fix.

The problem with rebasing is you might break every one of those commits, which defeats the purpose of chunking the work like that in the first place (since its no longer an honest reflection of what was happening/what worked at each point).

I usually rebase and then squash so that becomes a non-issue. I often find I want to commit more often than the code is in a working state, so I like to be able to erase that history later. I try to keep the whole branch small enough that it'a fine being in one commit.

Re: Fortunately, I don't squash my commits

#194

Post by BeetleB »

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.

Re: Fortunately, I don't squash my commits

#195

Post by joshribakoff »

KallDrexx wrote: post #145
dastx wrote: post #86

Earlier quoted context omitted.

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

I personally really dislike merge commits because it makes the tree really difficult to follow in most visualizations. If I'm trying to follow the main branch only to a certain point the graph is polluted with all the "WIP" side branch commits between head and the commit I end up getting to. It also defaults to causing the main to have a ton of commits with "Merged from XXXX branch" as the summary lines when that's n…

Use —first-parents and you get a log of only the merge commits themselves, a flat log

Re: Fortunately, I don't squash my commits

#196

Post by joshribakoff »

wtetzner wrote: post #153
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…

Also, can't you just revert the merge commit?

Yeah but I’m guessing most people commenting don’t know how. It’s:

git revert -m 1

Or something

Re: Fortunately, I don't squash my commits

#197

Post by chousuke »

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.

Personally I think of working in a branch as the process of creating a patch set. A patch in a series should only depend on its predecessors. You can submit more than one patch in a pull request.

I would never send out a patch set for review that includes all the "oops" "typo" "iteration 50" etc. commits I make as I work on code. Those are pure noise.

However, git is a tool for development, and during development I should be able to use git in whichever way is convenient for me: commit, rewrite and do whatever the hell I want with my local history. Not having that freedom is the primary reason why working with most non-distributed version control systems is such a pain.

When it comes to actually merging patch series to master, I like not doing fast-forward merges, since you maintain a natural grouping of the applied changes.

Re: Fortunately, I don't squash my commits

#198

Post by SXX »

Joker_vD wrote: post #125
SXX wrote: post #26

Earlier quoted context omitted.

I guess It's my development culture is flawed, but as one-man-team I always time constrained. So I sometimes don't have sufficient time to write too detailed commit messages. So I end up with "one commit per feature" rather than "one commit per logical change". So I actively using squash during interactive rebase when I prepare to merge completed branch since my commit history sometimes looks like this: Backend: new…

Well, uh, yes, that's what the commit history generally looks like (although we do generally put "JIRA-9999: " in front of all commit messages, for context). So what?

What I wanted to say that since I don't have that many people other than me looking into my code there no reason to preserve real development history of every feature and IMO 3 "feature commits" are preferable than my development mess of 50 "fix that fix this" commits.

Re: Fortunately, I don't squash my commits

#199

Post by saagarjha »

alxmng wrote: post #55
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…

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.

I don’t really like squashing on merge, since it destroys the commits I may have made. If you’re getting a PR from me and it has more than one commit, I have done that on purpose and you want to keep those separate.

Re: Fortunately, I don't squash my commits

#200

Post by jasonkester »

jefftk wrote: post #192

> 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 is a misunderstanding of what proponents of commit squashing advocate. Often, when working, you end up with multiple commits which represent a single change: remove debug logging and fix bug more logging debugging typo Squashing these commit…

I can only sit in amazement as I read this thread, watching seemingly smart people advocating throwing away history for the sake of tidiness. It's maddening.

Those are four commits. That's what happened. It does not matter that it's untidy. It's your history.

Just leave it. It will save you a lot of work some day when you need to find the error you introduced when you accidentally removed one too many lines on that "remove debug logging" commit.

Post reply on HN