On Sat, May 15, 2010 at 12:17 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Tay Ray Chuan wrote: >> On Wed, May 12, 2010 at 1:50 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >>> I cannot convince myself that this is a good change, as I've always >>> thought "ls-remote" output as something people want to let their scripts >>> read and parse. 9c00de5 may have given an enhancement to these scripts in >>> the sense that they can now respond to an empty input from the end user, >>> but this patch forces them to change the way they parse the output from >>> the command. > > Would 9c00de5 be so useful for scripts? I suspect the typical script > does > > git ls-remote "$remote" > > so to use the new default it would need adjusting. Right, existing scripts that use git-ls-remote are unlikely to be affected by 9c00de5, or this patch, for that matter. >> in this patch, the remote url is printed to stderr, instead of stdout, >> so existing scripts should be safe. >> >>> I also think this patch is solving a wrong problem. >>> >>> When an end user does not know which remote ls-remote would be talking to >>> by default, what else does he *not* know? Probably which remote "pull" >>> would be fetching from > [...] > > I think I see what you are saying, and for scripts, that really would > be the most useful thing. Then the script could use something like > > if test -z "$remote" > then > remote=$(git branch --get-remote --current) > fi > git ls-remote "$remote" Just curious - when did git-branch learn "--get-remote"? Or "--current"? -- Cheers, Ray Chuan -- 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