4 ms·
I think there are two perfectly acceptable schools of thought. One says that the history should be preserved exactly, because its important we keep a record of
by splike 9y ago
I think there are two perfectly acceptable schools of thought.
One says that the history should be preserved exactly, because its important we keep a record of exactly what happened.
The second says that its ok to rewrite history a little if that makes it more understandable.
I think you would put yourself in the first, and that's ok. I would put myself in the second because at the end of the day I value understanding over precision in git histories. I'm of the opinion that one cares about the commit I made to correct a missing semicolon.
- hdhzy 9y agoThe usual rule of thumb is not to modify (e.g rebase) published commits. So it's perfectly fine to adjust local commits before they go into centralized repo - from the point of view of an external observer the history is never destructively modified. This rule can be extended to topic branches or user owned branches with the caveat that others should not base their work upon the topic branch. Also remember git push --force-with-lease!
- james-skemp 9y agoAnd `git commit --amend` I missed a semi-colon or a file? I probably noticed right after I made the commit (and before I pushed it to the remote branch).
- maxxxxx 9y agoI am in the first because I don't think you should change history. But I think there is a need for tools that can show history like it would look after rebasing and squashing.
- fulafel 9y agoMaybe we need another layer of abstraction, maybe recorded as merge commits, that would present the summarized history.