Re: [ITCH] Specify refspec without remote

Junio C Hamano wrote:

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.

I agree that we need to get a "batching" push.default corresponding to
"matching" for multiple-remote setups.  However, I think we should
hold it off until my implicit-push patch is finished.  After using it
for a few days, I'll get a good idea about what this new push.default
setting should look like.

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.

In my opinion, it is a fundamental mistake to have more than one
person working on a branch.  There is one exception to this rule: it
is alright when there are only two people working on it, and one of
them is a "reliable fast-forward-only read-only upstream".  Let me
illustrate this with an example: I sometimes find myself working on
the master branch of git.git (fetch from origin: git/git.git, publish
to ram: artagnon/git.git).  This is because origin/master is an
"reliable fast-forward-only read-only upstream" (read-only in the
sense that it can only be updated with a git fetch).  My interaction
with it is limited to 'git rebase origin/master' on the master branch.
 I will never find myself manipulating it, and the rebase will never
fail unless my patches conflict with the new upstream.

As to why the setting is needed: I often work on more than one device*,
and I suspect a lot of people do this today.  I always fetch all
changes on my private branches before beginning work, unless I want to
end up in a confusing mess (I often rewrite history).

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.

Right.  The objective is to get 'git push' to _always_ DTRT.

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".

Hm.  I would argue that exploding push.default options is unhealthy,
and that we should move towards thinking of more fine-grained control
with different orthogonal options.  I'll first do it for pull
(autostash has been in progress for some time); then we can port the
relevant options to push.

* I still haven't made much progress on a design for config-sharing.  I
think I'm missing something big.