3 ms·
I don't get your point. Sure, the git log isnt the "cathedral", but also being able to change things quickly doesn't imply or necessitate this.
by parhamn 2y ago
I don't get your point. Sure, the git log isnt the "cathedral", but also being able to change things quickly doesn't imply or necessitate this.
- xnorswap 2y agoMy point is that I don't understand where the driving force for desiring to change it at all is coming from.
- dzaima 2y agoGit blame and bisect do care about the state of specific commits. During development of a thing it should be desirable to be able to handle/test just whatever the current thing is and clean up afterwards if necessary, without having to completely drop ability to use git. But this can impact later bisects - having temporary printf("fuck sadjkoisajhdfo")s spamming outputs, project entirely not building on a configuration that wasn't cared about at the moment (or worse, build successfully, but function off enough that it's not obvious that the commit was not intended to be touched). And then there's the general thing of having a feature that you had been working on, but want to move it to some other branch. Or you committed things out of order and the committed order doesn't actually build in the middle. Or you didn't commit some file/change and thus have a sequence of ten completely-non-sensical non-functional commits. The inverse question deserves asking - why would you want to leave in your primary commit history things not meant to ever be looked at?