Possible Duplicate:
When should the VCS history of a project be deleted?
I am experienced using svn and recently started learning git. I was quite shocked to learn that git has features that allow you to “rewrite history”.
Coming from svn, I had accepted as sacrosanct the source control principle that once a change is committed, there is no way to “undo” the commit itself… the most one can do is execute a later commit that effectively “reverses” the changes made in the earlier commit, but one can always reproduce the state of any commit that had been done in the past.
What is the rationale for changing this “principle”? Is there something different about git that makes this OK, or does the design of git reflect a different “philosophy” of source control that differs with the “philosophy” of svn?
7
The most important reason is security. Suppose you accidentally check in a file that contains a cleartext password, or some other sensitive information. Even if you check in a new version with the information deleted, it’s still visible in the history.
It can also be useful sometimes to make the history “cleaner”. For example, when you’re working in your own repository, you might check in multiple small changes as you experiment to see what works. When you finally get the change working, you might not want to push all those changes to another repository — so you can collapse them into a single change. As you’re developing in your private sandbox, you probably want a very detailed history of what changes you’ve made, and the ability to go back to previous versions. Once you’ve finally solved the problem, and the fix turns out to be, say, a self-explanatory one-line change, there’s no need to push all that history to another repo (perhaps one that acts as the central repo for the project).
9
Git follows the principle of not cementing policy into the code, that flexibility in the hands of highly technical users is more important than restricting them from making mistakes. Rewriting history is impossible to do in git without people noticing, as the SHA-1 hash for a commit and all subsequent commits will change. This is actually an improvement from svn, which doesn’t make it easy to rewrite history, but does make it possible, and makes it difficult to detect when you do.
1
CVCS and DVCS have big difference not only in first letter of abbreviations, but in core principles: for CVCS published commit is common shared history, committed but not pushed commit in DVCS – local personal history, which doesn’t affect anybody except author.
In latter case mutations of history are problem only of the one person, responsible for *their own mess and chaotic way of working.
And, at last, it’s just another style, style with the rights to life also. “Practice is the criterion of truth”, thus: if rewriting is not thrown away, nothing prevents to use it in tool, there it can be done easy.