Squash renders git log and bisect nearly unusable, that should be common knowledge, but I guess not. Normally there's never a reason to squash, small fixes can be done with git commit --amend for last commit or git rebase -i using the fixup keyword, but again only for really trivial things like typos and such otherwise same problems with log and bisect.
Fortunately, I don't squash my commits
11–20 of 333 posts
Re: Fortunately, I don't squash my commits
#12Do 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/squash commits, not 20 large ones.
Re: Fortunately, I don't squash my commits
#13If 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.
Re: Fortunately, I don't squash my commits
#14Do 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 nonfunctional also break bisect.
Re: Fortunately, I don't squash my commits
#15Do 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 always squash my commits and at my current place that is even enforced via phabricator
You can always land with `--merge`. That is what I do if it actually makes sense to preserve individual commits.
Re: Fortunately, I don't squash my commits
#16Do 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.
>Do people out there actually squash commits?
Depedends on the git flow being adopted by the commiters.
HNers constantly espouse how clarity is more important than cleverness. It may be the case that a single commit offers more concision than multiple commits which could be perceived as just more noise.
Re: Fortunately, I don't squash my commits
#17I 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
git log --no-mergesRe: Fortunately, I don't squash my commits
#18Do 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.
At my workplace we generate ~150 commits every week or two. There are a lot of trash commits and the history is completely unreadable.
I'm sure that's barely any compared to large companies, so I really question the value of commit history unless message guidelines are well enforced.
Re: Fortunately, I don't squash my commits
#19Do 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, but it's not something I do regularly.
In my case, it's generally because I'm preparing training material.
When I do that, I have two branches: dev and master. master is the one that is exposed to students, and dev is the one I use for prepping, testing and staging.
Sometimes, I may even have the dev branch in a private repo, or one that is associated with a different GH ID, like so: https://24ways.org/2013/keeping-parts-of-your-codebase-priva...
The main "gotcha" for me, is to make sure that I merge the master back into dev, after doing the squash. Makes life a lot easier, for the next squash.
Re: Fortunately, I don't squash my commits
#20If 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.
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.