Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
>
>> 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.
--
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