Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
> 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.
Please clarify the semantics of @{f}. Does it conceptually refer to
where the current branch is going to be pushed to (i.e. a pair of
(<remote>, <ref>))? Will we have a remote tracking branch for it
to record what we pushed there the last time? I am guessing that
your answers to both of these questions are "Yes", and frotz@{f}
would resolve to refs/remotes/there/topics/frotz-for-juno in the
sample set-up in the message you are responding to.
Side note: I do not think "fork" rings bell to the end
users. Who is forking from what? I am guessing you are
trying to make a short form of "the branch in my public
pepository I push this branch to, and other people would
consider it my fork of the upstream project", but it is hard
to do the reverse, i.e. a new person who is presented a word
'fork' to guess that you wanted to refer to the above by
that word.
I am not saying branch.<name>.push should not exist. Having a
finest-grained special case would be an escape hatch you can use
when you want to do something unusual.
But it has exactly the same issue as branch.<name>.pushremote;
adding it without having the single "all of my pushes go to here,
not to 'origin'" would have meant that for N branches you have to
set the same thing N times. We fixed it with remote.pushdefault
before the series graduated. If you only add branch.<name>.push,
then people have to configure it N times, for N branches they want
to push out.
Reusing the existing push refspecs was just a suggestion to solve
that issue, and I am not married to that particular design. You or
Felipe may be able to come up with a better alternative to achieve
the same goal and that is perfectly fine. I just wanted to make
sure that we do not force the user to repeatedly set the same thing
over and over in the common case.
By the way, about "crippling".
I do not think of a reason why you cannot implement that @{f} with
the 'single' matching (or its better version you may come up with).
If "git push" can figure out where it would push to, you certainly
should be able to borrow that same logic to see what tracking branch
you are locally using to track the last push result for the current
branch in response to @{f} request, no?
--
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