Junio C Hamano wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: >>> - struct remote *remote = remote_get(repo); >>> + struct remote *remote = pushremote_get(repo); >> >> "struct remote" has url and pushurl fields. What do they mean in the >> context of these two accessors? /me is confused. >> >> Is the idea that now I should not use pushurl any more, and that I >> should use pushremote_get and use url instead? [...] > At the programming level, you would still ask what the > URL to be pushed to to the remote obtained here, and would use > pushurl if defined, or url otherwise. Ah, I think I see. It might be more convenient to the caller if pushremote_get returned a remote with url set to the pushurl, but that would prevent sharing the struct with other callers that want that remote for fetching. So instead, the idea is something like remote: support a different default remote for pushing Teach remote_get() to accept an argument FOR_FETCH or FOR_PUSH that determines, when no remote is passed to it, whether to use the default remote for fetching or the default for pushing. The default remote for fetching is stored in the static var "default_remote_name", while the default for pushing, if set, is in "default_push_remote_name". Currently there is never a different default for pushing set but later patches will change that. If remote_get() gained a new required parameter, that would force all call sites to be examined (even any potential call sites added by new patches in flight) and there would no longer be need for the remote_get_1() function. What do you think? Jonathan -- 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