Ramkumar Ramachandra <artag...@gmail.com> writes:
> Junio C Hamano wrote:
>> If the user said "git push" without an explicit request to push to
>> "ram", and if branch.master.pushremote was not set to "ram", and
>> still the command "git push" pushed the branch to "ram", then I
>> would understand what you are worried about, but otherwise I do not
>> see how what you are saying makes sense.
> We currently have no system to differentiate between those two cases.
I am not sure what two cases you are talking about?
If you do not set anywhere (like branch.master.pushremote or
remote.pushdefault) to push to "ram", and if you did not say "git
push ram" but just said "git push", we will not push to "ram"
(otherwise it is broken). So if the push is going to "ram", the
user must have asked us to push there, either via the command line,
or these explicit configuration variables. And why do you need to
differenciate between the command line "ram" and configured "ram"?
After all, isn't the configuration merely a typesaver? If you know
often push to "ram", you configure to push there. If you don't, you
>> Or are you saying that with push.default set to upstream, only these
>> two forms should be allowed?
>> $ git push ;# no destination, no refspec
>> $ git push there ref:spec ;# both explicitly specified
> No, no. What I meant is:
> From the documentation of push.default, I _expect_ upstream to kick
> in only in the first case. In the second case, I _know_ that my
> push.default is inconsequential.
The push.default is meant to be in effect only when there is no
other stronger clue from the user for what to update (e.g. command
line refspec, remote.*.push). Because branch.*.push weatherbaloon
patch did not have any documentation update, it did not say it is a
yet another way to explicitly configure the push destination branch.
Perhaps that led to your expectation for upstream to kick in.
Of course, that requires, as you earlier pointed out, that the logic
to read from branch.*.push need to be moved out of the push.default
logic (in the weatherbaloon patch) and hosted to do_push() where it
checks if there is remote->pushrefspec. If branch.*.push wants to
defeat remote.*.push, then it should be checked before deciding to
use that configured remote.*.push.
> I want properly defined precedence and well-defined overall behavior.
Of course. There is no sneakiness.
As I already said, I personally do not know what branch.*.push buys
us, and will happy to drop 6/6. It is merely a weatherbaloon patch.
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