Re: [ITCH] Specify refspec without remote

Ramkumar Ramachandra [off-list ref] 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.