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

[Tay Ray Chuan <rctay89@gmail.com>]

On Sat, May 15, 2010 at 12:17 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Tay Ray Chuan wrote:
>> On Wed, May 12, 2010 at 1:50 PM, Junio C Hamano <gitster@pobox.com> 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