Re: [PATCHv3] Documentation: triangular workflow

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Junio C Hamano <gitster@pobox.com> writes:

>     * Introduction.  As a summary, here are the four configuration
>       variables you'll be using to make it easier to arrange.

I'd actually skip this, and keep configuration variable names for later.
The very point of these --set-upstream & friends options is to allow the
user to work without knowing about them. Typically:

git clone http://example.com/foo
cd foo
# hack hack hack
git commit
git push

=> no configuration variable involved for the user, and it just works.

So, instead of having a flow like "We need to configure
branch.<branch>.merge, and a shortcut to do so is to use
--set-upstream", I'd rather see "Let's push and ask push to remember
where we're pushing so that we don't have to tell it again next time:
git push --set-upstream origin master. Oh, BTW, internally this sets
branch.<branch>.merge.".

Talking about --set-upstream, it does not appear at all in your
patch. Is this on purpose?


OTOH, an introduction that would motivate the workflow would be very
useful IMHO. I see many people using triangular workflows just because
"it's cool" and I can't be satisfied with this. Among real arguments:

* Allows contributor to work with Git even though they do not have write
  access to upstream.

* Symmetrically, this allows maintainers to receive code from
  contributors they don't trust a priori.

* This makes code review more efficient

* This encourrages clean history (because you can "rebase -i" and
  force-push as much as you want to your public fork before the code is
  merged)

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/