Re: Random thoughts on "upstream"

Junio C Hamano wrote:

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?