Christian Couder <christian.cou...@gmail.com> writes:
> By the way it should not be very difficult as a patch to do this and
> more was proposed a long time ago:
>
> https://public-inbox.org/git/4d3cddf9.6080...@intel.com/
Thanks for a link. The one I found most interesting in the thread
is by Avery [*1*], where he explains why "first-parent" bisection
makes sense in "many people develop topics of their own, and they
are aggregated into an integration branch" environment:
Basically, we push/fetch *all* the branches from *everybody* into a
single repo, and build all of them as frequently as we can. If you
think about it, if you have all the branches that someone might have
pulled/merged from, then you don't have to think of the git history
as a whole complicated DAG; you can just think of it as a whole
bunch of separate chunks of linear history. Moreover, as long as
people are careful to only pull from a branch when that branch is
passing all tests - which you can easily see by looking at the
gitbuilder console - then playing inside each of these chunks of
linear history can help you figure out where particular bugs were
introduced during "messy" branches.
It also allows you a nice separation of concerns. The owner of the
mainline branch (the "integration manager" person) only really cares
about which branch they merged that caused a problem, because that
person doesn't want to fix bugs, he/she simply wants to know who
owns the failing branch, so that person can fix *their* bug and
their branch will merge without breaking things.
[Reference]
*1*
https://public-inbox.org/git/aanlktinwbm9gczhgeqcboepov0_xv7ujyqvc7j13q...@mail.gmail.com/
