Jordan DE GEA <jordan.de-gea@xxxxxxxxxxxxxxxx> writes: > +Motivations > +~~~~~~~~~~~ > +* 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. I somehow don't think "even though" sits well here. You can work with Git all you want locally even if you do not have write access anywhere, but that is stating the obvious. Also, unless the only alternative you are contrasting "triangular" with is "a single central repository workflow", "may not trust" is not a unique advantage of "triangular". You can exchange patches and reviews with contributors just like you do. I think the more important thing to say instead of the above two is that this arrangement allows distributed workflow; you publish to your place at your own pace, they pull from you if and when they choose to, and they publish their result to their place 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? If you are contrasting "triangular" with "a single central repository everybody pushes into", then one big advantage "triangular" can have around "code review" is that it allows reviews before the code hits the authoritative history of the project. If your project works with a single central repository everybody pushes into, things tend to run in reverse--after you push questionable stuff into the project history, somebody else has to spot problems, go in and fix it after the fact. > +* Encourages clean history by using `rebase -i` and `push --force` to > +your public fork before the code is merged This is a side-effect of "review before merge" mentioned earlier. > +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` > +=================================== Wouldn't it be much simpler to manage if you instead start from a clone of **UPSTREAM** and then fork **PUBLISH** and push your work out to the latter? You do not have to do per-branch configuration that way, no? 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. It smells like you are deliberately presenting a more cumbersome way, as a prelude to add even more configuration that is not necessary if you started in the right direction in the first place. -- 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