Re: [PATCH 6/6] push: honor branch.*.push
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 24, 2013, 16:53 UTC
- Message-ID
- <7vbo6vbgbs.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CALkWK0=a40hACGYApN7odrTytDmoRG_00_Q=EuaHuQ_=h8LBkg@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
Show 8 quoted lines
> 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 don't.
Show 11 quoted lines
>> 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.