Re: Adding push configuration to .git/config

[Junio C Hamano <gitster@pobox.com>]

Steffen Prohaska <prohaska@zib.de> writes:

> On Nov 22, 2007, at 2:48 AM, Junio C Hamano wrote:
> ...
>> An alternative could be to split [remote "name"] url into two
>> variants, fetch-url and push-url.  While fetching by default
>> from two places without telling from which one does not make any
>> sense, pushing by default to two different places is quite a
>> normal thing to do, and we already do support more than one url
>> entries in [remote "name"] section used for pushing.
>>
>> If we were to do this, it might also make sense to rename the
>> word 'origin' we use for the default remote name to 'default' or
>> something.  People with shared repository workflow would fetch
>> from one repository and push back to the same repository, so the
>> distinction would not matter, but for others who need something
>> like you suggest, the default repository for fetching and
>> pushing are different, and while you may still consider where
>> you fetch from your 'origin', where you push into is not your
>> 'origin' anymore.
>
> I like this idea.
>
> But in addition, we should have a branch.$name.push line that
> can contain a remote head to push to.

Yes, but.

At that point, I think you would introduce a mismatch between
the traditional semantics of refspec and what you are trying to
do, unless you are careful.

The traditional semantics of refspecs-tied-to-remote is strongly
based on the assumption: "I will push to this remote when these
local branches are all ready to be pushed out, and they will all
go there together as an atomic update.  When I am _that_ ready
to push, it does not matter which local branch I am on.  The
branches that matter are all in good shape when I push."

You are making the behaviour of push dependent on which branch
you are on.  During such a push, it is safe to assume that the
current branch is ready to be pushed out, but other ones can be
very much un-ready.  The user needs a safety valve to prevent
other branches from being pushed out.  Otherwise the user would
not be adding branch.$name.push to begin with.

It would probably need to become a target ref or a list of <URL,
target ref>, not a list of general refspecs like the value for
remote.$there.push variable.  For example, you would want to say
"while on master, push it to repository A as refs/heads/master
and to repository B as refs/remotes/satellite/master", which
would be a typical arrangement if you are working on a satellite
machine, A is the shared central repository and B is mothership
to your satellite machine.  The specification would talk only
about the target ref (not just "'can contain' a remote head to
push to"), and the source ref would always be the current
branch.

I guess you could use general refspec on branch.$name.push and
implement the safety by requiring (1) only one refspec appears
for such a variable, and (2) the LHS of the refspec matches the
$name of the branch, in order to make the parsing easier and to
keep the syntax uniform.

Or maybe I am being overly cautious again not to introduce any
more unnecessary user confusion, and just should give them even
longer rope to hang themselves.  I dunno.