Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > How will adding remote.pushdefault have any > impact, unless I explicitly remove this branch-specific remote > configuration? Besides, without branch.<name>.remote configured, I > can't even pull and expect changes to be merged. If the triangle topology is the norm for your project, I would expect that it would be pretty common to have all of your branches pull from one place and have all of them push to another place. In the central repository workflow, it is very common that all of your branches pull from one place and all of them push to the same place. In the bigger picture, forcing to set the branch specific remote is a mistake in the first place; in the longer term, you should be able to say "My project uses the central repository workflow" once and you should be able to pull without branch.master.remote; just record where the default "origin" for all branches is. I think the per-branch branch.*.pushremote is actively making things worse by repeating the same mistake for the triangle topology. You should be able to say "My project uses the triangle workflow" once and specify two remotes, where you pull from and where you push to, no? A per-branch override, be it branch.*.remote or brnach.*.pushremote, is useful to give an escape hatch in order to handle special cases with additional flexibility. But making it the sole mechanism and forcing the user to repeat the same "which remote does it use" all over the place does not sound like a solid engineering. -- 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