Re: [PATCHv4] Documentation: triangular workflow

["Philip Oakley" <philipoakley@iee.org>]

From: "Ramkumar Ramachandra" <artagnon@gmail.com>
> 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.

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

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