Argues for mutable local history, and hence rebase.
I think all of these arguments apply also to global history, at whatever level.
But I want immutability as much as possible.
Again, I conclude that it is not the absolute history we what to mutate. It is our VIEW of the history.
(Although there are valid reasons to really want to edit history, e.. to drop stuff that you are not legally allowed to use.)
2 comments:
JW says things like "If enough commits just came down, your feature branches won’t even show up on the same screen as master any more".
Basically complaining about the PRESENTATION of the history.
IMHO that's a reason to fix glog, not to mutate the history. It is a reason to amend the presentation of the history, but not the raw history.
I'd prefer a rebase that left the pre-rebased branch around at its original location. Perhaps hidden.
http://www.phabricator.com/docs/phabricator/article/Recommendations_on_Revision_Control.html#one-idea-is-one-commit
I'm okay on "Choose a strategy where one idea is one commit in the authoritative master/remote version of the repository."
In particular "having a strict policy where your master/trunk contains only merge commits and each is a merge between the old master and a branch which represents a single idea. Although this preserves the checkpoint commits along the branches, you can view master alone as a series of single-idea commits."
But I emphasize that even if you follow this diligently, you will probably encounter violations that require history editing on the trunk.
Post a Comment