Hagen Paul Pfeifer <hagen@xxxxxxxx> writes: > Imagine a "rebase feature branch" style of development. All features are > developed on separate features branch which are rebased on master and > immediately merged into the upstream master. I do not want to imagine such ;-) The only semi-sensible reason why people might want to always rebase on top of 'master' is to keep the history completely linear, so with such a workflow, there won't be a merge commit. But I think "rebase" part of your description is a red herring. If a development goes by always doing a new feature in a side branch and then merge the branch only after it is done to the 'master' branch, then bisecting only the commits on first-parent chain would often be a quick first-pass to find the topic whose merge into the 'master' branch introduced a breakage. From there you can dig down to each individual commit on the side branch. And for that, it is immaterial that the side branch gets rebased on 'master' and forced to become a merge with "--no-ff", of the side branch was developed on older upstream but in a careless way full of "oops, previous one I broke the entire world and it does not even compile; this commit fixes it" commits. So being able to stop at only commits on the first-parent chain is a valid and useful tool. "git bisect --first-parent" is one of the things that are sometimes asked for. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html