Junio C Hamano wrote:
> Actually, I suspect that you shouldn't even need to do that
> pros-and-cons analysis, because the 'single' thing should cover as a
> natural extension of the existing infrastructure. You should only
> need to have something like this:
Which is the exact argument I presented on the other thread. However,
Felipe has a point: we shouldn't cripple @{f} (I think "fork" is a
good name for it) in the name of generality. Think of what
remote.<name>.push and branch.<name>.push are actually going to be
used for:
remote.<name>.push are most probably going to be used with wildcards
(like in the Gerrit case): I don't mind if @{f} is not able to tell me
where my branch will go (and it's probably even a pseudo-ref, in which
case the answer is really meaningless). The limitation doesn't affect
remote.<name>.fetch, because @{u} only operates between remote
branches and local branches, not at the ref-mapping level.
branch.<name>.push cannot be used with wildcards, and @{f} is pretty
straightforward to determine in this case. When the information is
easily available for end-user consumption, why would we _not_ want to
expose it by stuffing branch.<name>.push into remote.<name>.push
configuration?
So, I think the way forward is:
1. Introduce @{f[ork]} to show $(branch.<name>.pushremote or
remote.pushdefault)/$(HEAD). We can update 'git status' to show this
information as well: the ahead/ behind with @{f} is no less important.
2. (optional) Make remote.<name>.fetch non-mandatory. Currently, a
lot of git-core breaks unless this is present, and this is an annoying
wart.
3. Introduce remote.<name>.push. Make it clear that it is intended
for the Gerrit-user. @{f} cannot be determined with this [*1*].
4. Introduce branch.<name>.push for a branch-specific override to
remote.<name>.push. @{f} can be determined when this is in effect.
[Footnotes]
*1* Do we want to do some magic wildcard-expansion to get/set @{f}
anyway? In which case, branch.<name>.push is really not necessary.
Which approach is less ugly?
--
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