Re: [PATCHv4] Documentation: triangular workflow

[Junio C Hamano <gitster@pobox.com>]

Jordan DE GEA <jordan.de-gea@grenoble-inp.org> 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.