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

81–90 of 333 posts

Re: Fortunately, I don't squash my commits

#81

Post by avar »

josephg wrote: post #61
vemv wrote: post #22

In a given team, mandating the squashing of commits essentially means admitting that pull requests' branch histories tend to be far from semantically valuable. Which can be perfectly fine, as it's hard to ensure that all developers use Git in an optimal way (I'm thinking of intentful use of interactive rebasing), uniformly. The only problem I find is when squash proponents claim their choice is superior. It's not; it…

Right. The problem is that are two use cases for commits: - a historical, fine grained log of changes - and a log of merged features. There's value in keeping both of these data sets. But the commit log as it stands can't easily serve both masters. Once you can see the problem for what it is, the solution is simple. Instead of conflating these two use cases into the concept of a 'commit', we need separate tooling for…

If you consistently use feature branches and have meaningful summary commit messages in the merge commits as they land on the mainline branch what you're describing is simply:

    git log --max-parents=1
    git log --min-parents=2
E.g. try this on the git.git repository (not perfect there, since Junio doesn't use this pattern all the time), but it's good enough for a quick demo.

The most useful convention in a DAG like git is to have the topology of your commits reflect your workflow.

Re: Fortunately, I don't squash my commits

#82

Post by grumple »

Kihashi wrote: post #12
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 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 projects.

Re: Fortunately, I don't squash my commits

#83

Post by mcv »

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 do read the git commit history, and specifically to find problems like these. Squashing commits indeed sounds like a terrible idea to me.

There are also people who insist you always need to rebase your commits before pushing, in order to get a nice, linear history, and again I disagree. It's fine when you're rebasing a very short (single commit) history, but for a long history, it not only gets very tedious, but when it introduces new bugs halfway through that history, you may not notice. You will notice later, and then tracking that bug you end up in the middle of your own (rebased) history and you may wonder why you ever did something so stupid, when the actual cause of the bug was the merge of two histories at the end of your work.

I do rebase sometimes, but only when the history is short and I can easily see what I'm rebasing. A history longer than 2 commits should not be changed.

I never squash.

Re: Fortunately, I don't squash my commits

#84

Post by swalsh »

m12k wrote: post #66
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…

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.

Re: Fortunately, I don't squash my commits

#85

Post by reallydontask »

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.

From experience of working with new CI/CD systems where one doesn't quite understand what's failing due to ... reasons.

It's really quite easy to get into the 50s or close to 100 commits in a branch, which can lead to a horrendously messy history.

There are also people that like to commit before the try something locally and their branches are effectively a mess.

All of the above is magnified in a monorepo environment, where you might have thousands of commits a day against master if it weren't for enforcement policies that force a squash.

Re: Fortunately, I don't squash my commits

#86

Post by dastx »

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.

> squash merge into shared branches

Why not just rely on a merge commit instead?

Re: Fortunately, I don't squash my commits

#87

Post by timvdalen »

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 depends on the situation. If I'm merging a feature branch that has a lot of commits that effectively make up one feature (because a dev had to go back and forth or because there was a lot of feedback), I might squash those commits into one before I merge it into master.

As mentioned elsewhere in the comments here, that also makes it a lot easier to revert said feature if something goes wrong.

Re: Fortunately, I don't squash my commits

#88

Post by Gaelan »

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.

Re: Fortunately, I don't squash my commits

#89

Post by bluGill »

m12k wrote: post #77
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…

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

If git has a concept of branches like mercurial has it would be a lot easier as you can actually see what branch your commits attached to.

(there are pros and cons of both approaches - this is a con of the git approach, I'm not knowledge about enough about esoteric details to comment on if git actually made a bad choice or just a compromise)

Re: Fortunately, I don't squash my commits

#90

Post by OJFord »

aurelianito wrote: post #29
fs111 wrote: post #6

Earlier quoted context omitted.

Merge commits are noise, a clean history is has no merge commits

If you squash all the merge requests, you get ONLY merge commits.

A 'merge commit' is the commit that ties together two strands.

    *   merge commit
    |\
    | * branch work
    | |
    | * branch work
    |/
    *
If you squash to merge, typically you're also going to rebase it (equivalently, if it's more familiar, cherry-pick the squash onto the branch your 'merging' it into).

    *     squash cherry-picked / rebased
    |   * both branch works squashed
    | * | branch work
    | | |
    | * | branch work
    |/_/
    *
(In this case the target branch could have been fast-forwarded, but this also works if there's some other work on the mean time:)

    *     squash cherry-picked / rebased
    |
    *     something unrelated
    |   * both branch works squashed
    | * | branch work
    | | |
    | * | branch work
    |/_/
    *
Post reply on HN