Fortunately, I don't squash my commits • Hacker News Board

Re: Fortunately, I don't squash my commits

#21

Post by [deleted] » Mon, Oct 05, 2020, 11:49 AM UTC

NateEag wrote: post #13

ZephyrBlu wrote: post #7

If you use Pull Requests with squashed commits, you can do exactly the same process as described here by isolating the issue to a PR then restoring the branch and bisecting from there. It seems like a small price to pay for a clean history, given the rarity of occurrences like this.

It seems like a needless price to pay, since the whole point of keeping history is to help analyze problems and past states. The author has only used bisect for a head-scratcher once, but I've used it often, sometimes to pin down bugs in code I'd never even looked at before. That's not feasible if the commits are huge.

[deleted]

Re: Fortunately, I don't squash my commits

#22

Post by vemv » Mon, Oct 05, 2020, 11:49 AM UTC

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's only superior if you aren't willing to maintain great history as you work on a given branch.

Of course there are also added benefits to a fine-grained history, as the article mentions.

My experience having maintained a production app with a fine-grained semantic history for 5 years is overwhelmingly positive. Understanding root causes, confidently reverting things etc becomes a much quicker job - particularly important when production is red.

Re: Fortunately, I don't squash my commits

#23

Post by flohofwoe » Mon, Oct 05, 2020, 11:49 AM UTC

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 on large PRs on a case-by-case basis, especially when they have a lot of very small and silly commits (fix this, fix that, wip, ...) but implement a very specific feature which required a lot of experiments that didn't end up in the final PR. And yes, I use the commit history very frequently, so it's important for me that this doesn't contain too much noise.

If I need to bisect a bug that was introduced by the PR I still can do this in the original branch.

Re: Fortunately, I don't squash my commits

#24

Post by stepsrabbit » Mon, Oct 05, 2020, 11:50 AM UTC

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.

If you always work in feature branches and commit often (which you should IMO) it makes perfect sense to squash on merge. It gives you a nice history that only contains relevant commits instead of having a bunch of “added tests”/“fixed XYZ”/“remove debug log”/etc commits.

With some discipline this makes the commit history actually worth reading and makes git blame a useful tool.

Re: Fortunately, I don't squash my commits

#25

Post by thombles » Mon, Oct 05, 2020, 11:51 AM UTC

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 it would be a hassle.

Re: Fortunately, I don't squash my commits

#26

Post by SXX » Mon, Oct 05, 2020, 11:53 AM UTC

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 set of APIs for XYZ
   Backend: implement feature X (+ some long comment)
   Frontend: implement feature X
   fix for feature backend
   fix for backend API XYZ
   front fix
   backend fix

Yeah again I know I could do better, but yeah I use squashing for this reason. A lot.

Re: Fortunately, I don't squash my commits

#27

Post by np_tedious » Mon, Oct 05, 2020, 11:54 AM UTC

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.

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 feel the article's author kind of overstated it here. Say 5 to 10 commits of this size were squashed together. Git bisect would've taken him 90+% as far and he'd have to read code or manually trial and error changes just slightly more. The binary searchable problem space would be slightly smaller, and the linear manual effort space slightly bigger. Less good, but really not that big of a deal.

Re: Fortunately, I don't squash my commits

#28

Post by NateEag » Mon, Oct 05, 2020, 11:54 AM UTC

ZephyrBlu wrote: post #20

NateEag wrote: post #13

Earlier quoted context omitted.

It seems like a needless price to pay, since the whole point of keeping history is to help analyze problems and past states. The author has only used bisect for a head-scratcher once, but I've used it often, sometimes to pin down bugs in code I'd never even looked at before. That's not feasible if the commits are huge.

You do keep the history in the branch, it's just out of the way unless you really need it. Also, the method I described has nothing to do with commits. PRs and small commits aren't mutually exclusive.

You have to go dig the branch out of the central repo, though, which is annoying and takes time.

That was the price I was thinking of.

You're certainly right that PRs and large commits are orthogonal.

Re: Fortunately, I don't squash my commits

#29

Post by aurelianito » Mon, Oct 05, 2020, 11:55 AM UTC

fs111 wrote: post #6

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!

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

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

Re: Fortunately, I don't squash my commits

#30

Post by jeremyjh » Mon, Oct 05, 2020, 11:56 AM UTC

ZephyrBlu wrote: post #7

If you use Pull Requests with squashed commits, you can do exactly the same process as described here by isolating the issue to a PR then restoring the branch and bisecting from there. It seems like a small price to pay for a clean history, given the rarity of occurrences like this.

It makes the initial bisect easier and faster as well, because every commit is a fully working one, and there are no trivial commits that still have to be rebuilt and bisected over. Plus all the commits are found in the order they were introduced to master, rather than randomly interleaved with other feature branches that were built at the same time. Personally I would think any kind of branch cleanup to get the history of a feature branch into a presentable state is a significant price to pay. I've only had to restore a PR branch a handful of times to find the particular culprit.