Re: Solve continuous integration (pending head / commit queue) problem using git

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Feb 13, 2010, 22:11 UTC
Message-ID: <alpine.LNX.2.00.1002131640200.14365@iabervon.org>
In-Reply-To: <32541b131002120942w50a29e7cjf2c10820b3286017@mail.gmail.com>

On Fri, 12 Feb 2010, Avery Pennarun wrote:

Show 17 quoted lines

> On Fri, Feb 12, 2010 at 11:37 AM, Jan Koprowski <jan.koprowski@gmail.com> wrote:
> > Now. My idea. There is some revision tagged as "stable". *Clone* and
> > *pull* operations is somehow "overloaded" from server side and always!
> > return last revision tagged as stable. After compiling external tool
> > just move tag to another revision which pass all tests. Of course
> > there is some additional parameter (for example --last or --unstable)
> > which can clone fine way of repository.
> >
> > Two questions.
> > 1) Maybe I try to invent the wheel again. Is there any way to take the
> > effect without overloading standard git behaviours.
> > 2) If not how overload git behaviors on git "server side" repo?
> 
> In general, code that lies to you about what's the most revision is
> evil.  Sometimes you *do* want to fetch that revision it's lying to
> you and saying doesn't exist, precisely because you'd like to help fix
> it before integration.

I think a more suitable detail here would be to have the remote system respond to pushes by stating that it's taking your push request under advisement, but cannot give an immediate verdict for that request (and it may want to let you know that it's updated a different ref of its choice that you didn't intentionally request).

$ git push
   f99642a..e70de97  HEAD -> master (proposed, not updated)

$ git log --oneline origin/master f99642a Original commit

(wait for external signal, like getting a confirmation email)

$ git fetch
   f99642a..e70de97  maaster    -> origin/master

$ git log --oneline origin/master f99642a Your commit

I think the only thing that would be needed would be a way for the remote server to report that it's not updating the ref, but it is planning to act on your request, so that your local git can give a non-error without updating the remote branch inappropriately. (Presumably, the server would have used a pre-update hook to give this response, which would have enqueued the request in the CI system; when the CI system likes a change, it can push and the hook would detect that it's actually the CI system and let the update happen).

	-Daniel
*This .sig left intentionally blank*