Hi, On Wed, May 12, 2010 at 1:50 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Tay Ray Chuan <rctay89@xxxxxxxxx> writes: > >> After 9c00de5 (ls-remote: fall-back to default remotes when no remote >> specified), when no repository is specified, ls-remote may use >> the URL/remote in the config "branch.<name>.remote" or the remote >> "origin"; it may not be immediately obvious to the user which was used. > > 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. 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 and what branch it would be merging with? Doesn't > he have a better command to use to learn that information to reorient > himself when he is lost that way? I'm not sure if there's a command to determine the remote - I'd be interested to know it, if there's one. That aside, I believe this patch as an attempt at improving usability. Compare (pre-patch): $ git ls-remote (scratch head) $ git-x # to determine which remote we listed refs from with (post-patch): $ git ls-remote The advantage is minor, but I feel there's some added convenience. -- Cheers, Ray Chuan -- 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