13 ms·
One of the disadvantages of rebase is that it leads to a history where most of the commit have never existed in that exact form an any machine and so have never
by fhars 2y ago
One of the disadvantages of rebase is that it leads to a history where most of the commit have never existed in that exact form an any machine and so have never been built or run. This may interfere negatively with git bisect, which assumes that you can run and test the software at every commit. A squash and rebase workflow doesn't suffer from this problem, but then you end up with huge commits that may make it hard to pinpoint the exact change that causes a new misbehaviour.
Of course, having a merge based workflow doesn't guarantee that people only commit source that runs, so bisect might be broken anyway, and you get a messy history on top of that, unlike the beautiful clean line of a rebase based workflow, that makes it look like the system was developed by people of superhuman mental clarity.
- afdbcreid 2y agoWait. If `git bisect` is anyway identifying merge commits only (since those are the only on history), how are you supposed to get advantage of the supposedly superior smaller commits?
- Izkata 2y ago`git bisect` hits every commit, not only merge commits. They're saying if you used squash-merge (which is a special kind of rebase), the small commits don't exist anymore so there's no way for bisect to find the small commit that caused the problem. Regular merges and non-squashing rebases both keep the small commits so bisect will find them.