Re: [PATCH] add ls-remote --get-push-url option
Ben Boeckel maths...@gmail.com writes: Not sure if it would be better to make a new variable or to reuse the existing one. I'm reusing it currently because it makes it easier to ensure they are mutually exclusive. Please keep me CC'd to the list; I'm not subscribed. Thanks, --Ben Ben Boeckel (1): ls-remote: add --get-push-url option Documentation/git-ls-remote.txt | 7 ++- builtin/ls-remote.c | 15 +-- 2 files changed, 19 insertions(+), 3 deletions(-) Probably get-url makes (some) sense because ls-remote is a fetch that does not actually fetch anything. But get-push-url to ls-remote makes _no_ sense whatsoever. ls-remote and fetch do not have to know or care about push-url; they do not even have to know there exists a thing called git push ;-) Wouldn't git push -v -n or something suit your needs already? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add ls-remote --get-push-url option
Ben Boeckel maths...@gmail.com writes: With some sed, yes, but then so would `git remote show` just as useful too (and in that case, why does --get-url exist either? comes to mind). Either carelessness let it slip in, or it came before 'git remote show'. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add ls-remote --get-push-url option
On Fri, Jul 31, 2015 at 12:02:14 -0700, Junio C Hamano wrote: Ben Boeckel maths...@gmail.com writes: With some sed, yes, but then so would `git remote show` just as useful too (and in that case, why does --get-url exist either? comes to mind). Either carelessness let it slip in, or it came before 'git remote show'. Would adding `git remote show --url $remote` and `git remote show --push-url $remote` be acceptable? --Ben -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add ls-remote --get-push-url option
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add ls-remote --get-push-url option
On Fri, Jul 31, 2015 at 11:40:12 -0700, Junio C Hamano wrote: Probably get-url makes (some) sense because ls-remote is a fetch that does not actually fetch anything. But get-push-url to ls-remote makes _no_ sense whatsoever. ls-remote and fetch do not have to know or care about push-url; they do not even have to know there exists a thing called git push ;-) Wouldn't git push -v -n or something suit your needs already? With some sed, yes, but then so would `git remote show` just as useful too (and in that case, why does --get-url exist either? comes to mind). Our use case is that we have some scripts which setup the project with the right remotes and such. To do this, we detect if your remotes are set up properly already and not ask if things are OK already. This is currently done with git config --get remote.$x.pushurl, but `pushInsteadOf` is not expanded and causes false positives. Where would a utility to have git expand its `pushInsteadOf` aliases make more sense? Being right beside `insteadOf` expansion made sense to me (certainly more than some locations for certain flags and actions, but that boat sailed long ago :) ). --Ben -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add ls-remote --get-push-url option
Ben Boeckel maths...@gmail.com writes: On Fri, Jul 31, 2015 at 12:02:14 -0700, Junio C Hamano wrote: Ben Boeckel maths...@gmail.com writes: With some sed, yes, but then so would `git remote show` just as useful too (and in that case, why does --get-url exist either? comes to mind). Either carelessness let it slip in, or it came before 'git remote show'. Would adding `git remote show --url $remote` and `git remote show --push-url $remote` be acceptable? It is not just acceptable; I think git remote is a much better place to have something like that. Or even git remote get url [$there], git remote get push-url [$there]. 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. 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
