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.

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.