On Mon, Nov 24, 2014 at 08:55:13PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > However, I think what removed the confusion for me in your --only=both > > proposal was the presence of a "both" option, since it made it more > > clear that is not what no-option means. So what about just "--push", > > "--fetch", and "--both"? > > I think that is the set that is most sensible, at least > syntactically, among the ones I heard so far in this thread. > > However, one thing still makes me wonder.... > > After doing "set-url --fetch" and nothing else, because the user > never said "--both" or "--push", does the user get a configuration > where "git push" fails? Or does "set-url --fetch" still gives us > remote.nick.url and causes "git push" to also go there? I think the latter. And that makes sense to me. Push falls back to fetch at runtime. And you never set a push url, so that's what happens. But it is not symmetric. We do not fall back fetch to push. We _could_, but that is a separate issue (one for git-fetch, and not git-remote). And I do not think it is one anybody is particularly asking for. We could also stop making push fall back to fetch. But I think people would find that irritating. I dunno. I think there has always been an implicit "subordinate" relationship between fetch and push URLs, with fetch being the "main" one. Maybe that is so ingrained in me at this point that I do not see a problem with the asymmetry. -Peff -- 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