3 ms·
Not only is it not strictly necessary to record an accurate history, but it's explicitly desirable to rewrite history. Effective git use starts with frequent an
by Sir_Cmpwn 8y ago
Not only is it not strictly necessary to record an accurate history, but it's explicitly desirable to rewrite history. Effective git use starts with frequent and thoughtful rebasing. Merge commits are supposed to show up in the UI, for the reason you said - recording it when it happens. But it's only useful when it needed to happen, during the normal course of development this is not usually the case.
- fulafel 8y agoSo what are the costs of preserving history that exceed the benefits? Benefits include at least (1) tracking down merge errors, (2) safety from the train wrecks when someone inevitably rebases and merges the same code, (3) additional resolution in the the actual history of the code as it happened including dead ends as failed experiments to learn from? I can think of only one well founded case for wanting to rewrite history (instead of adding metadata to the history, such as merge commits and revert commits), and that is polisihng the history after the fact to hide what happened in the sausage factory. This may be a legit reason if you are not working in a safe environment or otherwise want to prepare for a future adverserial setting with some people who will see the history. A special case of this is when you accidentally commit a secret into the code, but that case has satisfactory technical recipes already. If we want to improve the s/n in the log messages, a good avenue is better commit messages and metadata for the merges. For example in a github PR based workflow the main change note in each unit of work is the PR's description, and the individual commit messages are just minor notes along the way.