3 ms·
you shouldn't change history once you make it public, how hard is that? that's the golden rule, if you promise something to be immutable, stick to your promise
by aulin 6y ago
you shouldn't change history once you make it public, how hard is that? that's the golden rule, if you promise something to be immutable, stick to your promise
- outsomnia 6y agoTags are immutable. Branches are mutable. You can add to them and refactor patch series that are on them, equally valid in the eyes of git. For example a development branch has no implied "promise" about stability of its history, it is much better to not only refactor the code but also refactor the history so sub-patches are squashed into the single feature patch that they logically belong to, and not spawn lives of their own. There is no reason to run that kind of development branch like a stable "branch of record".
- jariel 6y ago'Don't shoot yourself in the foot with a gun - how hard can that be to understand'? And yet people do it all the time. The 'rule' is easy enough to understand. But it's not always clear 'why' that is (in many cases, it won't matter), or when exactly it applies. In the lowest common denominator cases, the rule is not so hard to follow, but it can get messy quickly and there are many ways to break the rule.