Re: [PATCH] git-remote: distinguish between default and configured URLs

[John Keeping <john@keeping.me.uk>]

On Wed, Jan 16, 2013 at 01:45:36PM +0100, Michael J Gruber wrote:
> 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@example.com:"]
>>         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@example.com: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?
> 
> 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.

OK.  I like the new format, I was just wondering if it was a simple
enhancement to indicate a pushInsteadOf URL specially as well.

> 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...")?

Given that it's not a trivial enhancement, I'd accept the argument that
someone who has configured pushInsteadOf can be expected to understand
the underlying git-config semantics of "git remote set-url".


John