Re: [git-for-windows] Re: Continuous Testing of Git on Windows

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 14, 2017, 23:11 UTC
Message-ID: <xmqq1sv074h7.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAP8UFD1+AgBVqSh=wHteM3uKO+55ZqqD4cHzBUfN0KTPXyvutQ@mail.gmail.com>

Christian Couder <christian.couder@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.6080405@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_xV7uJyQvC7J13qO15@mail.gmail.com/