# Clarifications for merge workflows

3 messages from 2010-03-11 to 2010-03-11. Participants: Markus Elfring, Junio C Hamano.
Thread: https://gitlist.dev/t/22983

## Markus Elfring, 2010-03-11 11:12

Subject: Clarifications for merge workflows
Message-ID: <4B98D015.40401@web.de>
URL: https://gitlist.dev/e/4B98D015.40401%40web.de

```
Hello,

Some informations are available in the manual about distributed content
management workflows.
http://kernel.org/pub/software/scm/git/docs/gitworkflows.html#_merge_workflow

I find that a few details are missing to achieve a better understanding for the
merging of branches.

Use case:
A contributor pushes an update suggestion from the personal repository "ABC" to
a topic branch in a public repository "SHARE" on a separate server. An
integrator reviews the proposed changes. If they are accepted, the integrator
will choose a repository where the merge should be performed next.
- 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?

Regards,
Markus

```

## Junio C Hamano, 2010-03-11 12:08

Subject: Re: Clarifications for merge workflows
Message-ID: <7v63532h82.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7v63532h82.fsf%40alter.siamese.dyndns.org
In-Reply-To: <4B98D015.40401@web.de>

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

> - 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.

```

## Markus Elfring, 2010-03-11 13:02

Subject: Re: Clarifications for merge workflows
Message-ID: <4B98E9CC.9000700@web.de>
URL: https://gitlist.dev/e/4B98E9CC.9000700%40web.de
In-Reply-To: <7v63532h82.fsf@alter.siamese.dyndns.org>

```
Thanks for your explanation.


> 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.

Does any observable difference exist if the data synchronisation would be
performed in the other direction?


> 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.

I guess that it matters a bit if the published repository "SHARE" is the leading
and authoritative storage location.

Regards,
Markus

```