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

Tay Ray Chuan wrote:

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

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.

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.

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"

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