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

121–130 of 333 posts

Re: Fortunately, I don't squash my commits

#121

Post by rmrfrmrf »

golergka wrote: post #74
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…

The fix is very easy: forbid fast-forward merges, and then you can always revert the merge commit of particular feature branch. As for cleanliness of history, everything should be as simple as possible, but not simpler. Squashing and rebasing is destroying history, which often could be valuable, as OP shows.

forbid fast-forward merges?!!?!

Re: Fortunately, I don't squash my commits

#122

Post by alkonaut »

thombles wrote: post #25

One obvious requirement for bisect to work is that your code builds on every commit - and so does everybody else participating in the git history. Straw poll - do you enforce this? If so, for literally every commit, or do you use partial squashing to maintain this property? While that's certainly a _desirable_ property, I've never really been concerned if, say, the penultimate commit on a PR failed CI. It feels like…

What (I assume) is normal is that you have PR validation and CI builds that only maintain the stable shared branches.

If the validation isn't extremely fast (seconds or minutes) then maintaining it for every commit is almost impossible. It would just get other side effects like people avoiding commits because they don't want to run an hous-long test suite more than once.

Re: Fortunately, I don't squash my commits

#123

Post by Aeolun »

matheusmoreira wrote: post #109
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…

A merge commit works just like a squashed commit except it keeps all history. This is precisely why it's sensible to avoid fast-forwarding since that operation discards the fact that a branch existed in the first place. It's better to always have merge commits. They can be reverted just as easily. I don't understand why merge commits aren't the default in git.

If you can fast forward the fact that the branch ever existed was irrelevant, since the branch is a direct child of what you based it on. Just with a different name.

Re: Fortunately, I don't squash my commits

#124

Post by delecti »

grumple wrote: post #82
Kihashi wrote: post #12

Earlier quoted context omitted.

I find the individual commits on feature branches to be more noise than signal after they are merged . They can be useful during review, sometimes, but mostly I want a cleaner history. > they really would like a complete story, not 20 gargantuan commits that contain 3 years of development That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge…

When you have to find a subtle one line breakage that happened years ago, you’ll be happy that you had a single commit with 30 lines of code instead of a squashed commit with 3000. It makes it much easier to isolate the case of a problem and fix it in many cases. I’m asked “how long has this been broken and what caused it?” and answer it via git blame or bisect probably every few weeks. This is life on legacy project…

I think you just highlighted one source of the disagreement. Nobody on any team I work with would accept a PR with 3000 lines of change. Each team had a policy, whether formal or informal, to break large work items across PRs so they were more easily reviewable. I would say that 300 lines changed is getting towards the bigger end of what we would accept. If your choice is between 30 or 3000 lines changed per commit, then for sure I'd pick 30, but above either I think a 300 line limit is more sensible.

Re: Fortunately, I don't squash my commits

#125

Post by Joker_vD »

SXX wrote: post #26
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.

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?

Re: Fortunately, I don't squash my commits

#126

Post by falcolas »

swalsh wrote: post #84
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.

Fore removing code that's buggy in production. It's way easier to find and remove 1 commit.

Isn’t that what rolling back releases for? i.e. revert the container (or whatever your unit of release is) to the previous version? If you’re removing individual commits and re-releasing (rolling forward), you’re still at risk of being down, because you’re not going back to a known good release.

Re: Fortunately, I don't squash my commits

#127

Post by Aeolun »

rmrfrmrf wrote: post #121
golergka wrote: post #74

Earlier quoted context omitted.

The fix is very easy: forbid fast-forward merges, and then you can always revert the merge commit of particular feature branch. As for cleanliness of history, everything should be as simple as possible, but not simpler. Squashing and rebasing is destroying history, which often could be valuable, as OP shows.

forbid fast-forward merges?!!?!

For the purspose given that would work. But it feels icky.

Re: Fortunately, I don't squash my commits

#128

Post by mkesper »

mcny wrote: post #53
Kihashi wrote: post #12

Earlier quoted context omitted.

I find the individual commits on feature branches to be more noise than signal after they are merged . They can be useful during review, sometimes, but mostly I want a cleaner history. > they really would like a complete story, not 20 gargantuan commits that contain 3 years of development That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge…

> That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge/squash commits, not 20 large ones. With the people I've worked with, I'd say most don't commit at all until they think the code is "ready" and they commit all at once. In the teams I've worked with, squashing vs not squashing isn't the question. I just want them to commit/push as soon a…

You need to squash your commits, then: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

Re: Fortunately, I don't squash my commits

#129

Post by falcolas »

Gaelan wrote: post #88
barrkel wrote: post #80

Squashing gets you in the habit of force pushing, and force pushing greatly increases the risk of clobbering someone's work. I've seen a lot more hours wasted on lost commits than I find credible to be wasted in slightly more verbose history. Squashing also turns cherry picked commits into merge conflicts. I'm not a fan. I can always go back to the feature PR and read the ticket details and diff commentary when I wan…

I'm no squash fan either, but git very rarely actually clobbers data. (As long as it's been committed at some point, and wasn't just sitting in the working tree.) `git reflog` can get back pretty much anything, as long as it happened relatively recently.

Until a garbage collection process trims those. You may control such on your local machine, but you don’t on the remote repo.

Re: Fortunately, I don't squash my commits

#130

Post by rmrfrmrf »

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.

depending on what im doing, i'll do squashing, fixups, and commit reordering in an interactive rebase prior to merging to at least reduce the number of noise commits.
Post reply on HN