Hi everyone, here is the fact, working with an asymetric workflow is not as easy as it could be. There are many options only setting by hands. And they are not easy to use, to understand and sometimes there are not suitable.
This is an example of what git could do : Environment : - You have the main repository -> A. - You have the fork repository of A -> fA - You have the clone of fA on your computer. - You want to work on fA/master and synchronize your branch A/branch1 with A/master So, you need to link the pull request to A/master and the push request to fA/branchA. Configuration : - branch.branchA.remote with A - remote.pushDefault with fA or branch.branchA.pushRemote with fA - branch.branchA.merge with fA. The steps to set those parameters are not user friendly, not complete and mistakes can happen(with --set-upstream for example) We are working on it and have solutions about it. Please, tell me what is the best for you and why ? Here is the solutions : 1. a. add the config var : remote.pullDefault b. add the config var : branch.<name>.pullRemote c. add `git pull --set-default` in order to set remote.pushDefault d. add `git pull --set-remote` in order to set branch.<name>.pullRemote With that solution, git will have a complete configuration with : - branch.<name.>remote, branch.<name>pullRemote and branch.<name>.pushRemote. - remote.pullDefault, remote.pushDefault 2. a. add `git pull --set-default` in order to move branch.<name>.remote to remote.pushDefault b. add git pull --set-remote` in order to move branch.<name>.remote to branch.<name>.pushRemote With this solution, we only add options for commands and not in config file. You can add your solution. I think that the first one is the best for now and for the future. The second one seems to be the easy way to implement but not the best. What is your opinion ? Best Regards. Jordan DE GEA ENSIMAG 2A - ISI jordan.de-...@ensimag.grenoble-inp.fr -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
