Re: [PATCH RFC 0/8] introduce 'git remote add --push' and 'git clone --push'

[Paolo Bonzini <bonzini@gnu.org>]

> If I have a local branch X, is it conceivable that if I ever want to push
> it out to elsewhere on a regular basis, I would likely to push it to the
> same branch at the same remote?

Yes.  The exception could be if you push to multiple remotes---but in 
that case, you have to issue multiple push commands anyway.  X -> (R,Y) 
is not a function, but (X,R) -> Y is.

> Are these all?  What I am trying to get at is if we can tweak the rules
> without introducing too much configuration variables to cover all these
> cases.
>
> Traditionally, we said:
>
>      $ git push $there $ref
>
> is _always_ a shorthand for
>
>      $ git push $there $ref:$ref
 >
> If we somehow tweak
> this "$ref is a shorthand for $ref:$ref" rule to account for the tracking
> branch.*.merge gives us, perhaps we can make the push easier to use.

This is nice indeed.  My questions are:

1) can we assume backwards compatibility is not a problem?  Or, in other 
words, would this be 1.6.5 or 1.7.0 material?  In the past, the list has 
usually been very cautious about that, but if there's good reasons I 
guess the answer can be "yes".

>   (4) "git push" is a synonym for "git push R" where R is the value of
>       branch.X.remote, or "origin" if there is no such configuration.  This
>       will in turn trigger rule (1) above.
>
>       We could optionally make it a synonym for "git push X" (where X is
>       the name of the current branch), which would invoke rule (3) above,
>       which in turn would invoke rule (2) above.  Perhaps "push only the
>       current branch" option in the configuration, or "git push HEAD" from
>       the command line, would trigger this alternate behaviour.

[i.e., looking up branch.*.remote for the current branch].

2) if I understand correctly, then "git push HEAD" would behave like 
push.default=tracking rather than push.default=current.  If so, how do 
you provide push.default=current behavior?  (Or maybe you don't care).

Would this apply to remote.*.push = HEAD too?  (I think so).  Are the 
backward compatibility issues stronger in this case?  (I also think so).

3) if the previous item turns out to be a problem, should we invent a 
new kind of refspec?  "HEAD:" is free to use, is it a good idea?  (I 
don't like it).

4) From an implementation point of view, how well will it fit the 
existing code, or rather will it have to be special-cased all over the 
place?  I already didn't like the single special case I have in the "git 
push --current" patch, though I think it's unavoidable.

> I think one of the workflows quoted as the original motivation of Finn
> Arne's series that added push.default also falls naturally out of this.

That's true, and I actually liked the idea very much.  The fact that it 
raises many questions is not necessarily a point down---adding new 
configuration keys is definitely simpler to flesh out, but it may be 
that it only reaches a local maximum of simplicity/expressiveness.  In 
my case the combination refspec/autosetuppush/pushHeadOnly is very 
expressive, but it requires to be wrapped by porcelain "git remote 
add"/"git clone" for the average user.

In the past I've seen the development of git follow the line of adding 
more knobs to allow the experts to tweak them, but that could also be a 
byproduct of the audience that this ML reaches.

In this case, I think the choice depends on how much effort can be 
invested in answering the above questions.

Paolo