From: Jonathan Nieder <jrnieder@gmail.com>
Date: Fri, 14 May 2010 16:17:44 GMT
Subject: Re: [PATCH v2] ls-remote: print URL when no repo is specified
Message-ID: <20100514161743.GA1957@progeny.tock>
In-Reply-To: <AANLkTinxm8hwX53LE9_7rDPoKs9UnGAyFFfVcoh-WGxE@mail.gmail.com>

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.

Run by hand, 'ls-remote | grep heads' can be quite useful.

> 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"

which would be much better than

  git ls-remote ${remote:+"$remote"} 2>/dev/null

because it does not suppress error messages.

For manual use of ls-remote, on the other hand, I can see the use of
the reminder.

Jonathan