Re: [PATCHv3] Documentation: triangular workflow

Junio C Hamano [off-list ref] 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/