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

61–70 of 333 posts

Re: Fortunately, I don't squash my commits

#61

Post by josephg »

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 each of these use cases. The commit log should probably house the historical record. And then we need a way to mark a set of commits as belonging to a particular feature's development. That could be achieved either by adding special support in git or via convention using commit messages.

Either way, I want to be able to see the commits in my repository grouped by the feature that they belong to. And I want that data set browsable on github, referenced against the corresponding github issues when thats appropriate.

Re: Fortunately, I don't squash my commits

#62

Post by strken »

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…

One can branch and then merge features, and get easily revertible commits and a full history at the same time.

Of course, there are caveats for reverting a merge - finding the right parent adds another failure-prone step, and your team can get in all sorts of trouble if they try to work with the branch without reverting the revert.

Re: Fortunately, I don't squash my commits

#63

Post by cvrajeesh »

aurelianito wrote: post #3

I never understood the need to squash commits (or rebase). If you do merge requests and use merge commits (like GitHub or gitlab do). A "nice" history is a small script away. It should even be a part of the GitHub/gitlab gui. Do not loose information about the development history!

rebase will give you linear history, merge doesn't provide you that

Re: Fortunately, I don't squash my commits

#64

Post by barrkel »

FeepingCreature wrote: post #14
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 squash commits. Well, I rebase so that changes are logical rather than historical. This is because when people read the commit history, which actually happens regularly, they would actually like a complete story, not 15 commits of "fix audit", "fix review" and "fix typo" - let alone refactors where previous work in the PR is thrown out, which you can by definition never care about. Commits so small that they're non…

Bisect doesn't have a problem with intermediate broken states, actually. It's why git bisect skip exists. It may not be able to pinpoint an exact commit though.

Re: Fortunately, I don't squash my commits

#65

Post by OJFord »

maccard wrote: post #41
eptcyka wrote: post #8

Earlier quoted context omitted.

I don't think having a history full of "Fix the shaver, maybe yaks don't need 6mm trim" with subsequent "Fix shaver again, yaks need as low as a 3mm trim" with some more intermediate commits help understanding what happened either.

That's much better than looking at a file in a 300 file commit and seeing "merged from XXXX" with no information as to why that one line was changed. I'd much rather spend 30 seconds parsing through the 10 yak shaving commits than have to go trawling through old commits on a file to find the most likely owner of it to ping on slack.

That's not what would happen though, by default the resulting commit message contains the messages from all those squashed into it.

Re: Fortunately, I don't squash my commits

#66

Post by m12k »

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…

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.

Re: Fortunately, I don't squash my commits

#67

Post by clinta »

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.

Everyone who works on Linux must rebase and squash commits so that every commit builds and passes tests, and does a single thing. More about how Linux uses git:

https://www.mail-archive.com/dri-devel@lists.sourceforge.net...

https://www.linux.com/news/why-linuxs-biggest-ever-kernel-re...

Re: Fortunately, I don't squash my commits

#68

Post by alkonaut »

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.

You don't have to squash into ONE commit just because you squash.

If I make 10 commits I can squash it into two logical commits (e.g. refactor, add feature) then I merge the branch with those two.

If the branch is small and has 3 commits that are one logical change, then I might as well squash to main instead of merging.

Commit history is readable regardless (I'd never use anything but --first-parent ever).

Re: Fortunately, I don't squash my commits

#69

Post by FrankSansC »

It is not related to squashing or not. One of the main rule when using git (or any other VCS I guess) is that each commit should be atomic.

IMO squashing commits is something that you should do locally, not remotely. For example I'm currently debugging a fairly large C application on an embedded system. Each bug has it's own branch. When debugging / testing / trying to fix it I tend to do a lot of commits. When the bug is fixed I do an interactive rebase to pick / drop / squash commits in order to have only a clean one at the end (and then push it).

Re: Fortunately, I don't squash my commits

#70

Post by bwhmather »

Commit history serves two largely separate purposes:

1) To provide a code-level record of what has changed in individual files and why.

2) To provide a high-level record of what features were introduced and what bugs were fixed over a period of time.

Often people will forget about one of them when arguing for a particular approach.

Squashing can make 2 easier but annihilates 1. Rebasing gives you 1 but makes 2 difficult, or requires that you track high level changes in an external system. In theory, approaches using merge commits can give you both but they are often difficult to apply in practice.

Post reply on HN