Re: [PATCH] add ls-remote --get-push-url option

From: Ben Boeckel <mathstuf@gmail.com>
Date: Jul 31, 2015, 20:51 UTC
Message-ID: <20150731205142.GB6556@megas.kitware.com>
In-Reply-To: <xmqqzj2c3zoh.fsf@gitster.dls.corp.google.com>

On Fri, Jul 31, 2015 at 12:16:46 -0700, Junio C Hamano wrote:

> Or even "git remote get url [$there]", "git remote get push-url [$there]".

Looking at `git remote`'s existing subcommands, consistency there would be something like:

    git remote get-url $there
    git remote get-url --push $there

The new call could also show *all* remotes which will be pushed to, not just the first. Looking at the structure, it also has fields for multiple fetch urls. I would assume git would fetch the union of refs; not sure about conflicts and such.

Show 10 quoted lines

> Or to mirror the existing "ls-remote --get-url [$there]", which directly asks
> "where does this request go if I run it without '--get-url' option?":
> 
>     $ git push --get-url [$there [$refspec...]]
>     $ git push --get-refspec [$there [$refspec...]]
> 
> might be a better option.  The logic in "push" takes the current
> branch and configurations like branch.*.remote and push.default into
> account, so it is likely that you will get the exact information
> without too much code.

This is a little weird to me. `git push` is porcelain; `git ls-remote` feels more like plumbing (command-list.txt seems to agree). Maybe it is also useful since it takes these other configuration values into account. But maybe pushing has enough extra factors? Might it make sense in addition to a `git remote get-url`?

> I am not opposed to having a scriptable interface to obtain these
> pieces of information.  I was only objecting to teach ls-remote
> anything about push, which ls-remote does not have anything to do
> with.

OK. Thanks.

--Ben