3 ms·
Why is a clean linear history desirable? It's not reflective of how the product was built? Is it just for some naive desire of purity?
by richardwhiuk 9y ago
Why is a clean linear history desirable? It's not reflective of how the product was built? Is it just for some naive desire of purity?
- ubolonton_ 9y agoIt's easier to see commits of a branch grouped together in most history viewers. Even though sorting commits topologically can help, most history viewers don't support that option. When there is an undesired behavior that is hard to reason about, git-bisect can be used to determine the commit that first introduced it. With a normal merge, it will point to the merge commit, because it was the first time the 2 branches interacted. With a rebase, git bisect will point to one of the rebased commits, each of which already interacted with the branch coming before. Resolving conflicts in a big merge commit vs in small rebased commits is like resolving conflicts in a distributed system by comparing only the final states, vs inspecting at the actual sequences of changes.
- cryptonector 9y agoWho cares about how a product's sub-projects were put together? What one should care about is how those sub-projects were put together into a final product. To be sure, the sub-projects' internal history can be archived, but it needn't pollute the upstream's history. Analogously: who cares how you think? Aside from psychologists and such, that is. We care about what you say, write, do.