Hi, This series follows up a previous discussion with Junio and Jeff [1]. It attempts to support the triangular workflow, where the remote you're fetching from is not the same as the remote you're pushing to. `remote.<name>.pushurl` has already been discussed, and deemed as a poor solution to the problem [2]. [1/4] is a minor cleanup patch to make other patches consistent with the existing style. [2/4] introduces the infrastructure needed to allow [3/4] and [4/4] to be simple configuration-adding patches. [3/4] and [4/4] add the proposed configuration options. They're very simple patches, but the documentation is not so simple: I've documented all the side-effects of the other configuration option in each configuration option, to give the reader a comprehensive picture when reading one configuration option. I've put off implementing remote.default corresponding to remote.pushdefault, as Jeff suggested in [1], because it's currently not an itch; apart from the obvious symmetry, I don't know what purpose it serves: why would anyone want to fetch from a remote other than origin by default? Why wouldn't they simply swap that remote's name with "origin"? However, it's a nice thing to have for symmetry, and it should be trivial to implement: any interested person is welcome to pick it up. The series works as expected, and all tests pass. Thanks for reading. [1]: http://thread.gmane.org/gmane.comp.version-control.git/215763 [2]: http://thread.gmane.org/gmane.comp.version-control.git/215702/focus=215717 Ramkumar Ramachandra (4): remote.c: simply a bit of code using git_config_string() remote.c: introduce a way to have different remotes for fetch/ push remote.c: introduce remote.pushdefault remote.c: introduce branch.<name>.pushremote Documentation/config.txt | 23 ++++++++++++++++--- builtin/push.c | 2 +- remote.c | 60 +++++++++++++++++++++++++++++++++++------------- remote.h | 1 + 4 files changed, 66 insertions(+), 20 deletions(-) -- 1.8.2 -- 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