Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 24, 2017, 00:25 UTC
Message-ID: <xmqqfugy4pnx.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1704211135430.3480@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 7 quoted lines

> Part of the reason is that you push out all of the branches in one go,
> typically at the very end of your work day. The idea of Continuous
> Integration is a little orthogonal to that style, suggesting to build &
> test whenever new changes come into the integration branch.
>
> As a consequence, my original setup was a little overloaded: the VM sat
> idle most of the time, and when you pushed, it was overloaded.

I do not see pushing out all them in one go is making the problem worse for you, though.

As of this writing, master..pu counts 60+ first-parent merges. Instead of pushing out the final one at the end of the day, I could push out after every merge. Behind the scenes, because some topics are extended or tweaked while I read the list discussion, the number of merges I am doing during a day is about twice or more than that before I reach the final version for the day.

Many issues can be noticed locally even before the patches hit a topic, before the topic gets merged to 'pu', or before the tentative 'pu' is pushed out, and breakage at each of these points can be locally corrected without bothering external test setups. I've been assuming that pushing out all in one go at the end will help reducing the load at external test setups.