Re: [PATCH 2/4] push: make upstream, simple work with pushdefault

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

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Junio C Hamano wrote:
>
>> [...]
>
> Okay, so what you're saying makes sense.

That is not a very useful style of quoting; what did you just agree to?

I think we should step back and clarify the "to which repository the
push goes" and "what branch(es) in that chosen repository is
updated".  The former is determined by your original "triangular"
topic in the recent world order.

The push.default specifies the logic/algorithm to decide the latter,
when there is no stronger configuration is given (e.g. the push
refspecs in remote.*.push, and branch.*.push).

> - current: push "$(HEAD)".  No restrictions on destination.

This updates the branch with the same name the current branch on the
pushing side.

> - matching: push ":" to the destination specified by the current
> branch.

This updates the branches in the destination repository, for which
branches with the same name exists on the pushing side.

> - upstream: In the special case when fetch source is equal to push
> destination, push "$(HEAD):$(branch.$(HEAD).merge)".  Otherwise,
> fallback to current.  Useful in central workflows.

That looks to me as an inconsistent description.  If you are not
pushing to where you fetched from, that is not even central.

This is mean to update the branch that is fetched from and is
integrated with the current branch with the tip of the current
branch, so the branch at the destination repository that gets
updated is branch.$current.merge.  It further means that the
repository being pushed to must be the same as the repository we
fetch from; otherwise it is an error.

> - simple: [still haven't thought about what to do with this; I'm
> generally not in favor of artificially crippling functionality by
> erroring out]

In a central workflow (i.e. repository we fetch from to update the
current branch is the same as the repository we push the tip of this
branch to), this works the same as upstream, but the configured
branch.$current.merge has to be the same as the name of the current
branch in the local repository; otherwise it is an error.

In a triangular workflow TBD, but I think doing the same as current
may be a good starting point.

> Just like upstream respects branch.<name>.merge, current respects
> branch.<name>.push, making branch-level ref mapping in triangular
> workflows possible.

I do not know we want to make branch.*.push linked to current.  If
it is set, shouldn't that apply when push.default is "matching" and
other values?  That is why I threw it in the same category as the
traditional push refspecs in remote.*.push in the early part of this
message.