Re: Clarifications for merge workflows

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 11, 2010, 12:08 UTC
Message-ID: <7v63532h82.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B98D015.40401@web.de>

Markus Elfring <Markus.Elfring@web.de> writes:

Show 7 quoted lines

> - Log-in to the server and integrate the updates there.
>   or
> - Fetch the remote topic branch into the integrator's own local repository
> "XYZ", merge there and push the result back to the server.
>
> Which ways do you recommend to select the storage location where a merge will be
> applied first?

Personally, I would find the latter a more natural (and perhaps the only natural) solution to me.

Being distributed is just that. When I do my work, whether it is developing new things myself, reviewing others' patches or reviewing others' pull requests and accepting them (either "am", or "pull"), everything is done "locally" at the most convenient place for "me", and that convenient place happens to be where I primarily do my work. The tools, test procedures, and everything necessary for my work is already there.

And then the procedure to publish the result out, whether it is what I did myself, or what I helped to integrate into my history from others, is the same. I push the result out from that "local" place to the "public" one.

Of course, if you are always working on that "server", the fact that you are always working there makes it the most convenient place to do all of your work for you. But even in that case, you would not want to publish a half-integrated state out to the public only to confuse people, so the actual integration work may happen phisically on the "server" machine, but most likely you would be working in a repository on that machine that is separate from the one you let others to pull from, i.e. your public repository.