Ramkumar Ramachandra <artag...@gmail.com> 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.
> - 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
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
With "matching", because "ram" would not have this branch (you
decided not to publish it), "git push" on this branch won't push it
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)
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