John Keeping venit, vidit, dixit 16.01.2013 11:42: > On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote: >> The current output of "git remote -v" does not distinguish between >> explicitly configured push URLs and those coming from fetch lines. >> >> Revise the output so so that URLs are distinguished by their labels: >> >> (fetch): fetch config used for fetching only >> (fetch/push): fetch config used for fetching and pushing >> (fetch fallback/push): fetch config used for pushing only >> (fetch fallback): fetch config which is unused >> (push): push config used for pushing > > How does this interact with url.<base>.pushInsteadOf? > > I have a global rule to convert git:// URLs to ssh:// for pushing: > > [url "git@xxxxxxxxxxx:"] > pushInsteadOf = git://example.com/ > > With only a URL configured for a remote (no pushURL), I get (with Git > 1.8.1): > > origin git://example.com/repository.git (fetch) > origin git@xxxxxxxxxxx:repository.git (push) > > From the original discussion in this thread, I think that if I did > "git remote set-url --add --push <url>" it would replace my current push > URL, and the change to "(fetch/push)" doesn't help in this case. > > Should there be special handling for pushInsteadOf here? > > > John Thanks for pointing out this case. The new code would still list this as two separate URLs because they really are; whether they come from two config entries or from one being subject to two different insteadof expansions is completely opaque to builtin/remote.c, unless remote.c learns to stick that additional info into struct remote somehow. In short, the separate listing is correct, but in this case there's no improvement in readability. We could still say that (push)InsteadOf is a power feature and we want to help the "normal" case, but it's a bit half-assed. In the end we might even have to keep track of insteadof-expansions and display those also (i.e. "expanded from...")? Michael -- 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