From: "Ramkumar Ramachandra" <artagnon@xxxxxxxxx>
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?
-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html