Re: [PATCH v2] ls-remote: print URL when no repo is specified

On Sat, May 15, 2010 at 12:17 AM, Jonathan Nieder [off-list ref] wrote:

Tay Ray Chuan wrote:

quoted

On Wed, May 12, 2010 at 1:50 PM, Junio C Hamano [off-list ref] wrote:

quoted

quoted

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.

quoted

in this patch, the remote url is printed to stderr, instead of stdout,
so existing scripts should be safe.

quoted

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