31–40 of 333 posts
Earlier quoted context omitted.
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.
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…
TIL about `git bisect` and it's really vindicating.
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 always squash my commits and at my current place that is even enforced via phabricator
Phabricator’s preferred model, which is heavily influenced by Facebook, is to forgo feature branches entirely and just stack many small changes on top of each other, landing as and when you want (this doesn’t preclude you working on feature branches locally, of course, because Phabricator doesn’t care what your local checkout looks like).
Because of this, Phabricator considers each diff to be discrete, and if you have multiple changes making up a single feature they should in turn be broken down into separate diffs.
Personally, I think stacked diffs are the killer feature of Phabricator. Unfortunately I haven’t been able to find a similar flow with PRs (recently we migrated from Phabricator to GitHub for one of my projects), you end up fighting against the tool a lot.
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…
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 seems like madness any other way to me... why have a bigger granularity than a single merge commit?
Earlier quoted context omitted.
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.
How is this annoying or time consuming? It takes less effort than adding, committing and pushing changes.
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.
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.
I don't often (ever?) browse the history, but I _do_ regularly search the history using tooling, (git log | grep ), and more is more in that case, even if the history isn't perfect.
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…
Earlier quoted context omitted.
Yes they do. And it is frustrating. Specially frustrating when you ar the new guy and the history of the code does not tell what happened.
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.
Well scoped and well sized commits, squashed, and in my personal preference rebased, provide a commit history that's segregated on actual tickets/stories/features/fixes that I find are navigatable very far back.
I'd say squash usage is very much case by case. But yeah equating a feature like squash to large commits is a fallacy. It's a useful tool imo that can be misused, but that doesn't mean the tool is "bad".
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 want to continously deploy to production (with real users using it) you need a process to very quickly revert bad commits from it. At my last company with hundreds of developers, we would push to prod several times a day. Each deployment would have several devs changes included. A clean linear history is essential to making that process work.