3 ms·

> it only traces it to one giant hairball or another, ie, bisect is made useless The blog post is advocating a "squash, rebase, and merge" flow, which leaves e

• cryptonector 3y ago
  Right, squash-and-rebase is not very good. You want meaningful history. So if you have a feature branch that adds some feature consisting of N sub-features, R refactorings, B bug fixes, then you want N+R+B commits. The commits you squash are the "fixup" commits; all others stay. You also want good commit order. Basically, write your code, commit, then refactor your commits so that you get nice history of all the changes you made as if you were starting from the final state of play (because you are).
• keikobadthebad 3y ago
  Oh... well, for benefit of others since you seem to know well already, there's no need for merge at all if you are just adding patches that have already been rebased to the HEAD of the tree they're going on. They just go on top cleanly and naturally, and all right with the world. Consumers of the branch fast-forward as normal. There's a pure, linear history with no hairballs that people can bisect to patch granularity. Just say no to merge.