> I can't for the life of me understand this pursuit of a (fake) linear history. Because we, the rebasers, don't consider the repository to be "history". If y

> I can't for the life of me understand this pursuit of a (fake) linear history. Because we, the rebasers, don't consider the repository to be "history". If you stop thinking of it as history, your whole perspective changes. It may fool you into thinking that it's history because there are dates everywhere, but it's really just a big collection of ordered changesets. With that in mind: > - accidental reintroduction of commits rebased upstream are the result of wrongly rewriting history upstream. You can't rewrite history when history is replicated along several repos. Of course you can. Your local repo and the remote servers you have access to are malleable and can manipulated however you'd like. I happily force push when the situation calls for it. However, it does place a burden on everyone else who fetches/pulls from that repo and so one need to take that into consideration. For major screwups (like the 50gb file accidental checkin from the article), it's very, very good that this can happen. For one of my projects I'm using git-multimail[1] on our "master" repo and it handles force pushes brilliantly (sends out emails with a list of commits removed/added). This is a great way to communicate with the rest of the team when you have a rewrite-after-push culture. [1] https://github.com/mhagger/git-multimail https://github.com/mhagger/git-multimail