Re: [PATCHv3] Documentation: triangular workflow

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

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)