Re: [PATCHv4] Documentation: triangular workflow

From: Philip Oakley <philipoakley@iee.org>
Date: Jun 11, 2016, 19:31 UTC
Message-ID: <5A8F8EE0162B49818813DAEFD68F61DA@PhilipOakley>
In-Reply-To: <CALkWK0nJDwH27V9B+X2K=c_X2k82ZXnab1r1zR6_axipxT5gkg@mail.gmail.com>

From: "Ramkumar Ramachandra" <artagnon@gmail.com>

Show 12 quoted lines

> Junio C Hamano wrote:
>> Jordan DE GEA wrote:
>>
>> > +* Allows contributors to work with Git even though they do not have
>> > +write access to **UPSTREAM**.
>> >
>> > +* Allows maintainers to receive code from contributors they may not
>> > +trust.
>
> Triangular workflow is the ability to accept changes from contributors
> without mailing patches back-and-forth. Whether they send a pull
> request or

>       commit directly to the master repository

Surely, if they can do this then they do not need a distinct publish repo.

The triangle is necessary because of the accessibility 'standoff' between the upstream and local repos when a pull workflow is used.

Matthieu had clarified this (to me http://article.gmane.org/gmane.comp.version-control.git/296538) - I was (at that time) confusing the use of the fork as a home vault (with passive publishing) with the need for actively publishing a branch for a PR.

Show 52 quoted lines

>   when review is
> done, is inconsequential. Essentially, they maintain forks of
> upstream, which they work on at their own pace.
>
>> > +* Code review is more efficient
>>
>> I have no idea what data you have to back this claim up.  More
>> efficient compared to what?
>
> They're orthogonal. LLVM has one giant SVN server that everyone
> commits directly to. However, they review process is a lot more
> efficient than GitHub projects, because they use Phabricator. What
> does code review tool have to do with triangular workflow?
>
>> > +Preparation
>> > +~~~~~~~~~~~
>> > +
>> > +Cloning from **PUBLISH**, which is a fork of **UPSTREAM** or an empty
>> > +repository.
>> > +
>> > +======================
>> > +`git clone <PUBLISH_url>`
>> > +======================
>> > +
>> > +Setting the behavior of push for the triangular workflow:
>> > +
>> > +===========================
>> > +`git config push.default current`
>> > +===========================
>> > +
>> > +Adding **UPSTREAM** remote:
>> > +
>> > +===================================
>> > +`git remote add upstream <UPSTREAM_url>`
>> > +===================================
>> > +
>> > +With the `remote add` above, using `git pull upstream` pulls there,
>> > +instead of saying its URL. In addition, `git pull` can pull from
>> > +**UPSTREAM** without argument.
>> > +
>> > +For each branch requiring a triangular workflow, set
>> > +`branch.<branch>.remote` and `branch.<branch>.pushRemote`.
>> > +
>> > +Example with master as <branch>:
>> > +===================================
>> > +* `git config branch.master.remote upstream`
>> > +* `git config branch.master.pushRemote origin`
>> > +===================================
>
> It's much too simple now. Just `git clone <upstream>`, `git remote add
> mine <fork-url>`, and `git config remote.pushdefault mine`. Only the
> last line requires an explanation.

I note that you use 'mine', Jordan was proposing 'me', while I started using 'my'. It is useful to see these personal choices, especially as there is no 'origin' in the nominal triangular flow diagram.

Whether to use branch configs or remote configs is part of the clarifications.

Show 7 quoted lines

>
>> Instead you would set default.pushRemote to publish
>> just once, and no matter how many branches you create later, you do
>> not have to do anything special.
>
> I think you meant remote.pushdefault here?
>