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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Jun 13, 2013, 09:10 UTC
Message-ID: <CALkWK0mDDKETE1O=g7X5s5MJvU7UA_NQiMNESor_8=phW0WR-A@mail.gmail.com>
In-Reply-To: <7vobbdhjeg.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 7 quoted lines

> If you recall the earlier discussion on "@{publish} which is
> different from @{upstream}", one idea to allow mapping on the push
> end was to introduce "push.default = single" that would act as
> "upstream" when in "branch I fetch and integrate with is the same
> branch at the same repository the one I want to update with my
> result" workflow, and in a triangular workflow maps the branch being
> pushed using remote.$name.push refspecs (if exists).

I'm still resisting this idea, because I don't like these special-case push.default modes. If possible, I want to avoid introducing another one to the existing mess.

> [...]

Okay, so what you're saying makes sense.  I'm cooking the following idea:

- current: push "$(HEAD)".  No restrictions on destination.  The most
generic, sensible, and extensible one, in my opinion.

- matching: push ":" to the destination specified by the current
branch. [since I cannot know what I'm pushing in advance, I think this
is generally ugly]

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

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

Just like upstream respects branch.<name>.merge, current respects branch.<name>.push, making branch-level ref mapping in triangular workflows possible. Finally, remote.<name>.push is entirely orthogonal to all this, and is respected no matter what.

Am I making any sense?