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.
> 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
--
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