Junio C Hamano wrote:
> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html