On Tue, Apr 03, 2012 at 03:29:34PM -0700, Junio C Hamano wrote: > > Hmm. So this will actually detect "git push $URL" when $URL matches the > > remote's configured URL. I feel like this distinction has come up > > before, and we decided not to equate the two. But now I can't remember > > where (maybe it when fetching via URL versus via remote?). > > > > What should happen if there are multiple push URLs configured? > > This is me merely try to be extra nice without succeeding. > > Perhaps it was an ill-thought-out part of the patch. The reasoning was > that when you know that your 'origin' is at $URL, it might be irritating > if "git push $URL" did not do what "git push origin" did, but we can > always say 'origin' that is a remoteo nickname is different from $URL; a > remote nickname does not have to be _only_ substitute of the URL, but it > can do more for you. That would give you more incentive to define remotes > that you interact with often, while keeping the bare-metal flexibility > when interacting with other remotes in a one-shot fashion. Yeah, this better matches what we do with fetching, where "git fetch origin" will respect remote.origin.fetch, but "git fetch $(git config remote.origin.url)" will not. I do not care too much which way we go, but I think that it makes sense to be consistent in the two cases. > I personally would be perfectly fine if > > $ git push $URL > > that does not say what to push out how, regardless of push.default > settings, errors out. > > The same can be said when a remote has more than one URL to be pushed to. I actually think "git push $URL" makes sense for 'current' and 'matching'. I don't think people tend to do a lot of one-off pushes, but certainly I have done: $ git init $ hack hack hack $ commit commit commit $ ssh example.com git init --bare foo.git $ git push example.com:foo.git (and sometimes even followed by "cd .. && rm -rf foo", if my next step is to actually clone foo.git somewhere else). Having to say "HEAD" or ":" is not the end of the world (and in fact 'matching' already errors out in this case), but it's nice to do the right thing when it's obvious (i.e., for 'current'). > Personally I do not care too much about it, but this is one more reason > not to support "upstream" over "current" as the default setting. Agreed. -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