> I've recently come to realize a thing with git I really abhor. It > has a very loose view on history immutability. I've seen branches, > which claims to come from some point, where the branch is way older > than the revision it claims to have been branched off. Which > obviously is impossible. But history rewriting seems to be a > favorite pastime of git users.
That's not a fault of git; that's a fault of how some people use git. I recently had occasion to go through and expunge certain content from a (git) repo. It was neither convenient, simple, nor fast, even though the content in question consisted of two files whose names remained constant throughout their history. > For me, one of the really big points of VCS is that history is never > changed. I can go back and see what was done, where, to what. And git can be used that way. No VCS is ever truly never-change, unless you use write-once media to store it, and even then it is always vulnerable to reconstructing a new repo from the ground up based on the old repo. > Since git actually is multiple, independent VCSs, what happens on one > don't necessarily at all come across to another, and in the process > of aligning them, history have to be rewritten to even get close to > make some kind of sense. Not really; history doesn't _have_ to be rewritten. That's what merge commits are for. People just choose to rebase work instead of merging. (Personally, I think that's a mistake, for various reasons, but, as you point not, not everyone agrees.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B