Re: Adding push configuration to .git/config

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 22, 2007, 08:23 UTC
Message-ID: <7vd4u28z90.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <C297CFC3-8DD0-4EEE-8FD3-BF997F6E269A@zib.de>

Steffen Prohaska <prohaska@zib.de> writes:

Show 23 quoted lines

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