Junio C Hamano <gitster@xxxxxxxxx> 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/ -- 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