Tay Ray Chuan wrote:
> On Wed, May 12, 2010 at 1:50 PM, Junio C Hamano <gitster@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html