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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to