6 ms·

When I first read the often-repeated advice NEVER change public history or something along those lines I was like 'yeah, 'duh'. My opinion on that changed a bit

by stinos 7y ago

When I first read the often-repeated advice NEVER change public history or something along those lines I was like 'yeah, 'duh'. My opinion on that changed a bit though and I reckon this advice follows the standard pattern of good guidelines being falsely wrapped as strict rules which must never be broken. In practice: I only work in smaller teams and we use feature branches which get merged into master after review, having the netto effect pretty much no-one is ever working directly on master. So it if happens someone does something like pushing a commit only to figure out 2 days later it has a typo or even needs a small code change or anything which would improve the commit with trivial changes not really worth creating another commit, we just go ahead and fixup/rebase/force push i.e. rewrite public history. Since the rest of the team always does pull --rebase of master anyway and/or rebases feature branches this is not a problem at all.

unionpivo 7y ago
If you read last Linus message in the chain he says pretty much the same, it's not black and white, and sometimes you need to break the rules. (That said its still a good rule, and unless you know what you are doing you should follow it)
ptsneves 7y ago
In my opinion the force push option availability decreases proportionally with the number of users of a repo. In a repo where about 400 people work to make a force push we needed to get authorization from management and do it in a weekend. In my own projects I amend quite often and force push about 1/10 times.
Cthulhu_ 7y ago
Yeah, pretty much all projects are smaller than the use case Linux has; main differences are scale, number of contributors, hierarchy, etc. In Linux, iirc, there's a lot more sharing code via email and the like, peer-to-peer. In the rest of the world, it goes through a central repository. Anyway, a bit more flexible is that it's fine to rebase history and force push, as long as it's on your own branch or as long as everyone working on the same branch is aware that it's about to happen and acts accordingly. If they don't though, you're going to have a bad time. The most important thing is to be conscious of what effect your actions will have on others. And of course, never do it on master - and if for some reason you have to, take a good look at what caused the problem in the first place. It's good practice in most projects to lock down master in whatever repository host you use (e.g. github) and only allow changes via pull requests.
ajdlinux 7y ago
> In practice: I only work in smaller teams Are you using git in an open source project, or is this proprietary software within a single company?
- stinos 7y ago
  Mostly the latter, which of course makes it easier. The open source parts are either only open source in that they're publicly available but in reality there's no other users (we know of) or there aren't many users and they just deal with it e.g. in case of a fork of a more popular project where we have a feature branch which gets rebased on upstream regularly.
davnicwil 7y ago
The question is though, why would you even bother changing public history, even if you can work around the practical problems? In my view, the concept of a commit mapping exactly to a functional change, and therefore being able to be correct or incorrect, improved, etc, is going against the grain of what revision control is. A commit just is what it is. If it contains a typo, a bug, etc, you notice and fix it 2 days later and that's another commit. Git just describes what happens. What is the utility in pretending that didn't happen and rewriting the history of changes as if you never made that mistake? Who benefits? If you are concerned about keeping master 'stable' so that checking out any commit will result in a clean, working codebase, you can use abstractions on top such as tags to point out to people which commits are good and/or bad. I get the idea of a stable, neat git history as though you were all knowing and perfect is comforting, but it's also nonsense and trying to attain that is just wasted effort. Just let git describe what actually happened, yes it's chaotic, yes there is constant rapid iteration, mistakes made and corrected etc, but that's just the process of building stuff. That's the reason you shouldn't rewrite history. There are pragmatic exceptions, though, like writing out egregious errors like committing security keys that can't be quickly changed.
- stinos 7y ago
  Who benefits? We do, simply because it's less cognitive overhead to read log/blame output when it's less chaotic. This doesn't mean that there's zero chaos in the commit history of course. But less than when we'd just never fix simple mistakes right away.
  - pletnes 7y ago
    I figured this benefit would be much greater in a public-facing repo. After all, there’s often a few commits fixing minor linting errors etc just before the final merge. Rebasing these away is reducing noise by alot. Rebasing on master/stable/release branches is another story altogether.
- smcameron 7y ago
  Because git bisect.
dahart 7y ago
I’m all for staying flexible and realizing the rule isn’t absolute, but fixing a typo or improving a commit is a very low bar. On my teams, I reserve rebase on public history for more serious emergencies, like someone accidentally checking in security keys. It’s probably fine on a very small team, but pull with rebase doesn’t protect you from merge conflicts when someone rebases master underneath you, this is why the practice of rebasing public history is and should generally be considered an anti-pattern.
- kevsim 7y ago
  I get your point, but checking in security keys is cause to rotate keys, not to rebase and force push.
  - dahart 7y ago
    100% absolutely agreed if the keys were accidentally made public outside the org. If not, rotating keys is sometimes a bit more work than a quick rebase & push. It was the best example of an exception to the rule I could think about, but personally, my threshold for whether rebasing master is ever allowed might be closer to 'no if team is larger than 3 people, otherwise try not to, think twice, and ask everyone first.'
chousuke 7y ago
I think advice like this is always geared towards people who don't yet understand the reasons. It'll prevent them from making some real messes. When you really understand the implications of changing public history, you will also know when you can break the rule.

by stinos 7y ago

unionpivo 7y ago

If you read last Linus message in the chain he says pretty much the same, it's not black and white, and sometimes you need to break the rules. (That said its still a good rule, and unless you know what you are doing you should follow it)

ptsneves 7y ago

In my opinion the force push option availability decreases proportionally with the number of users of a repo. In a repo where about 400 people work to make a force push we needed to get authorization from management and do it in a weekend. In my own projects I amend quite often and force push about 1/10 times.

Cthulhu_ 7y ago

Yeah, pretty much all projects are smaller than the use case Linux has; main differences are scale, number of contributors, hierarchy, etc. In Linux, iirc, there's a lot more sharing code via email and the like, peer-to-peer. In the rest of the world, it goes through a central repository. Anyway, a bit more flexible is that it's fine to rebase history and force push, as long as it's on your own branch or as long as everyone working on the same branch is aware that it's about to happen and acts accordingly. If they don't though, you're going to have a bad time. The most important thing is to be conscious of what effect your actions will have on others. And of course, never do it on master - and if for some reason you have to, take a good look at what caused the problem in the first place. It's good practice in most projects to lock down master in whatever repository host you use (e.g. github) and only allow changes via pull requests.

ajdlinux 7y ago

> In practice: I only work in smaller teams Are you using git in an open source project, or is this proprietary software within a single company?

stinos 7y ago
Mostly the latter, which of course makes it easier. The open source parts are either only open source in that they're publicly available but in reality there's no other users (we know of) or there aren't many users and they just deal with it e.g. in case of a fork of a more popular project where we have a feature branch which gets rebased on upstream regularly.

davnicwil 7y ago

The question is though, why would you even bother changing public history, even if you can work around the practical problems? In my view, the concept of a commit mapping exactly to a functional change, and therefore being able to be correct or incorrect, improved, etc, is going against the grain of what revision control is. A commit just is what it is. If it contains a typo, a bug, etc, you notice and fix it 2 days later and that's another commit. Git just describes what happens. What is the utility in pretending that didn't happen and rewriting the history of changes as if you never made that mistake? Who benefits? If you are concerned about keeping master 'stable' so that checking out any commit will result in a clean, working codebase, you can use abstractions on top such as tags to point out to people which commits are good and/or bad. I get the idea of a stable, neat git history as though you were all knowing and perfect is comforting, but it's also nonsense and trying to attain that is just wasted effort. Just let git describe what actually happened, yes it's chaotic, yes there is constant rapid iteration, mistakes made and corrected etc, but that's just the process of building stuff. That's the reason you shouldn't rewrite history. There are pragmatic exceptions, though, like writing out egregious errors like committing security keys that can't be quickly changed.

stinos 7y ago
Who benefits? We do, simply because it's less cognitive overhead to read log/blame output when it's less chaotic. This doesn't mean that there's zero chaos in the commit history of course. But less than when we'd just never fix simple mistakes right away.
- pletnes 7y ago
  I figured this benefit would be much greater in a public-facing repo. After all, there’s often a few commits fixing minor linting errors etc just before the final merge. Rebasing these away is reducing noise by alot. Rebasing on master/stable/release branches is another story altogether.
smcameron 7y ago
Because git bisect.

dahart 7y ago

I’m all for staying flexible and realizing the rule isn’t absolute, but fixing a typo or improving a commit is a very low bar. On my teams, I reserve rebase on public history for more serious emergencies, like someone accidentally checking in security keys. It’s probably fine on a very small team, but pull with rebase doesn’t protect you from merge conflicts when someone rebases master underneath you, this is why the practice of rebasing public history is and should generally be considered an anti-pattern.

kevsim 7y ago
I get your point, but checking in security keys is cause to rotate keys, not to rebase and force push.
- dahart 7y ago
  100% absolutely agreed if the keys were accidentally made public outside the org. If not, rotating keys is sometimes a bit more work than a quick rebase & push. It was the best example of an exception to the rule I could think about, but personally, my threshold for whether rebasing master is ever allowed might be closer to 'no if team is larger than 3 people, otherwise try not to, think twice, and ask everyone first.'

chousuke 7y ago

I think advice like this is always geared towards people who don't yet understand the reasons. It'll prevent them from making some real messes. When you really understand the implications of changing public history, you will also know when you can break the rule.