[Arch-TK]

Does your project have a policy of compiling and running (and e.g. tests passing) at EVERY commit?

I can't imagine being able to easily enforce that without asking people to edit the correct part of their commit. It's maybe more difficult with gitlab/github interfaces where changing the middle of a sequence of commits will not render very well, but in email based workflows it works fine.

On the other hand, being able to bisect a project without having to worry about whether an unrelated issue is causing you to traverse the wrong branch of the bisect is an enormous advantage compared to the minimal effort required of keeping track of a modified (rebased) commit in the middle of a set of commits under review.

[rjmunro]

You can now use --first-parent when you bisect to ensure bisect doesn't go into branches but stays on the main branch.

https://git-scm.com/docs/git-bisect#Documentation/git-bisect...

[Arch-TK]

I don't see how this solves the problem of patches which fix up previous patches. This workflow doesn't require using merges, but it will introduce situations (irrespective of whether you use --first-parent or not) where patches fix previous patches potentially leaving a gap where code doesn't compile, doesn't run, or doesn't pass tests.

[Supermancho]

> I can't imagine being able to easily enforce that without asking people to edit the correct part of their commit.

I imagine something something githooks. However it might be enforced, it seems like a miserable way to develop.