Re: [PATCH 4/6] remote.c: introduce a way to have different remotes for fetch/push
From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:56:28
Junio C Hamano wrote:
Ramkumar Ramachandra [off-list ref] writes:quoted
if (name) name_given = 1; else { - name = default_remote_name; - name_given = explicit_default_remote_name; + if (pushremote_name) { + name = pushremote_name; + name_given = 1; + } else { + name = default_remote_name; + name_given = explicit_default_remote_name; + } }The code to read branch.$name.remote configuration flips explicit_default_remote_name to one when it is used to set the default_remote_name, and that controls the value of name_given in this codepath. At this point in the series, you do not have a corresponding branch.$name.pushremote, but your [6/6] does not seem to do the same. Why isn't it necessary to add explicit_default_pushremote_name and do the same here in patch [6/6]?
Sorry, I'm still trying to understand your comment. Okay, yes: branch.$name.remote does flip explicit_default_remote_name, because we need to know if the default remote name was explicitly given. Wait, how is explicit_default_remote_name used to set default_remote_name? Don't you mean name_given? It controls name_give, yes. At this point I don't have .pushremote, yes: I'm setting up for [5/6] and [6/6]. My [6/6] doesn't seem to do the "same"? The same thing as .remote? Are you asking why .pushremote doesn't flip explicit_default_remote_name like .remote does? Because .pushremote can only ever be specified explicitly: otherwise, it falls back to the .remote logic. Okay, next paragraph. Why isn't it necessary to add explicit_default_pushremote_name? Like I said, .pushremote can only ever be specified explicitly. There is no implicit fallback (like "origin"): it just falls back to the .remote codepath, if not explicitly specified. In other words, it's just a small override on the .remote codepath.