Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > Let us imagine that origin points to git/git.git (upstream), ram > points to artagnon/git.git and peff points to peff/git.git. I fork > off from upstream and have various local branches that only have > corresponding refs in ram (say implicit-push). Then, you fork off > from me, and have various local branches that only have corresponding > refs in peff (say implicit-push-next). I have peff as a configured > remote, because I routinely review the changes you make to my fork. > In this case, I must have: > > - push.default set to anything but matching, because matching makes no > sense in the multiple-remote scenario*. The "matching" style makes sense only when pushing to your default publishing repository, _and_ your work style is to finish working on all branches that matter before pushing things out. Instead of keeping a configuration file on your local end that says "here are the branches I want to publish", you let the remote side remember them for you. When pushing into other kinds of repositories (e.g. you can update some but not all of the branches, or you want to touch only some of them and not others even if you have enough privilege to update any of them) or when you do not "batch" and push out one branch as work on it is done, while other branches that you would eventually publish are still not ready, "matching" is not for you. > - remote.default set to origin, because this is where I get new code > from for all branches. OK. > - remote.pushdefault set to ram, because this is where I publish all > my refs to (whether branches or tags). I might have local branches > that I will never publish, but that's a separate issue. The point is > that all my tags will always be published here. Makes sense. The variable is to name such a publishing location. > - branch.implicit-push.remote set to ram, because this is the correct > upstream for the implicit-push branch. If "implicit-push" branch at "ram" is updated by other people and you may have to pull back from, you would need this for "git pull" (without arguments) while on that branch, I guess. But I got the impression from your scenario that "ram" won't be updated by anybody but you. So I am guessing that this may not be needed. > - branch.implicit-push-next.remote set to peff, because this is the > correct upstream for the implicit-push-next branch. Makes sense. You are building on top of his work. > - branch.implicit-push-next.pushremote set to null**, because I will > never want to push this branch. This becomes necessary only if you use push.default set to "current" (or "upstream"). If you mistakenly say "git push" (no other arguments), without this configuration you will end up pushing the branch out. With "matching", because "ram" would not have this branch (you decided not to publish it), "git push" on this branch won't push it out. It may be that adding push.default=current-but-do-not-create-anew could help. It is a cross between 'matching' and 'current', to say "consider pushing out the current one, but only when the other side already has one", and may help people who do not "batch". > (Note that branch.implicit-push.pushremote is unnecessary because > remote.pushdefault takes care of that) True. -- 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