From: Tay Ray Chuan Date: Sat, 15 May 2010 09:56:20 GMT Subject: Re: [PATCH v2] ls-remote: print URL when no repo is specified Message-ID: In-Reply-To: <20100514161743.GA1957@progeny.tock> On Sat, May 15, 2010 at 12:17 AM, Jonathan Nieder wrote: > Tay Ray Chuan wrote: >> On Wed, May 12, 2010 at 1:50 PM, Junio C Hamano 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