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

On Wed, Jan 16, 2013 at 01:45:36PM +0100, Michael J Gruber wrote:

John Keeping venit, vidit, dixit 16.01.2013 11:42:

quoted

On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:

quoted

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