threads / patch / 23757

patchls-remote: print URL when no repo is specified

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

## tl;dr

12 messages between May 9, 2010 and May 20, 2010. Diffs are folded; open one to read it.

replies: 11people: 5as markdown or json

Tay Ray Chuan· May 9, 2010, 14:42 UTC · lore

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.

In such cases, print a simple "From <URL>" line to indicate which repository was used. This message is similar to git-fetch's, and is printed to stderr to avoid breaking existing scripts that depend on ls-remote's output behaviour.

It can also be disabled with -q/--quiet.

Modify tests related to falling back on default remotes to check for this as well, and add a test to check for suppression of the message.

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
  This is a logical follow-up to the "optional repo" form of ls-remote
  feature. Myself, I was using the "no-repo" form of ls-remote and
  sometimes wondered where it was listing remotes from.
  Johnathan, do you think the tests involved might have any cross-
  platform issues?
 builtin/ls-remote.c  |   10 +++++++++-
 t/t5512-ls-remote.sh |   19 +++++++++++++++----
 2 files changed, 24 insertions(+), 5 deletions(-)
Show changes to 2 files +24 −6

builtin/ls-remote.c, t/t5512-ls-remote.sh

diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index 8ee91eb..34480cf 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -5,7 +5,7 @@

 static const char ls_remote_usage[] =
 "git ls-remote [--heads] [--tags]  [-u <exec> | --upload-pack <exec>]\n"
-"                     [<repository> [<refs>...]]";
+"                     [-q|--quiet] [<repository> [<refs>...]]";

 /*
  * Is there one among the list of patterns that match the tail part
@@ -34,6 +34,7 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
 	const char *dest = NULL;
 	int nongit;
 	unsigned flags = 0;
+	int quiet = 0;
 	const char *uploadpack = NULL;
 	const char **pattern = NULL;

@@ -67,6 +68,10 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
 				flags |= REF_NORMAL;
 				continue;
 			}
+			if (!strcmp("--quiet", arg) || !strcmp("-q", arg)) {
+				quiet = 1;
+				continue;
+			}
 			usage(ls_remote_usage);
 		}
 		dest = arg;
@@ -99,6 +104,9 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
 	ref = transport_get_remote_refs(transport);
 	if (transport_disconnect(transport))
 		return 1;
+
+	if (!dest && !quiet)
+		fprintf(stderr, "From %s\n", *remote->url);
 	for ( ; ref; ref = ref->next) {
 		if (!check_ref_type(ref, flags))
 			continue;
diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index 3cf1b3d..8508df8 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -57,12 +57,21 @@ test_expect_success 'dies when no remote specified and no default remotes found'

 test_expect_success 'use "origin" when no remote specified' '

-	git remote add origin "$(pwd)/.git" &&
-	git ls-remote >actual &&
+	URL="$(pwd)/.git" &&
+	git remote add origin "$URL" &&
+	git ls-remote 2>actual_err >actual &&
+	grep "From $URL" actual_err &&
 	test_cmp expected.all actual

 '

+test_expect_success 'suppress "From <url>" with -q' '
+
+	git ls-remote -q 2>actual_err &&
+	test_must_fail grep "From $URL" actual_err
+
+'
+
 test_expect_success 'use branch.<name>.remote if possible' '

 	#
@@ -78,10 +87,12 @@ test_expect_success 'use branch.<name>.remote if possible' '
 		git show-ref	| sed -e "s/ /	/"
 	) >exp &&

-	git remote add other other.git &&
+	URL="other.git" &&
+	git remote add other $URL &&
 	git config branch.master.remote other &&

-	git ls-remote >actual &&
+	git ls-remote 2>actual_err >actual &&
+	grep "From $URL" actual_err &&
 	test_cmp exp actual

 '
--
1.7.1.189.g07419
Jonathan Nieder· May 9, 2010, 22:01 UTC · re: Tay Ray Chuan · lore

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

Tay Ray Chuan wrote:
> when no repository is specified, ls-remote may use
> the URL/remote in the config "branch.<name>.remote" or the remote
> "origin"
[...]
> In such cases, print a simple "From <URL>" line to indicate which
> repository was used. This message is similar to git-fetch's
Makes sense.  The code and tests look sane.
Testing on Linux and Msysgit does not reveal any problems, either.

Thanks, Jonathan

Tay Ray Chuan· May 11, 2010, 17:20 UTC · re: Tay Ray Chuan · lore

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

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.

In such cases, print a simple "From <URL>" line to indicate which repository was used. This message is similar to git-fetch's, and is printed to stderr to avoid breaking existing scripts that depend on ls-remote's output behaviour.

It can also be disabled with -q/--quiet.

Modify tests related to falling back on default remotes to check for this as well, and add a test to check for suppression of the message.

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
  The sole difference from the previous patch is the use of test_cmp
  instead of grep in the tests.
 builtin/ls-remote.c  |   10 +++++++++-
 t/t5512-ls-remote.sh |   24 ++++++++++++++++++++----
 2 files changed, 29 insertions(+), 5 deletions(-)
Show changes to 2 files +29 −6

builtin/ls-remote.c, t/t5512-ls-remote.sh

diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index 8ee91eb..34480cf 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -5,7 +5,7 @@

 static const char ls_remote_usage[] =
 "git ls-remote [--heads] [--tags]  [-u <exec> | --upload-pack <exec>]\n"
-"                     [<repository> [<refs>...]]";
+"                     [-q|--quiet] [<repository> [<refs>...]]";

 /*
  * Is there one among the list of patterns that match the tail part
@@ -34,6 +34,7 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
 	const char *dest = NULL;
 	int nongit;
 	unsigned flags = 0;
+	int quiet = 0;
 	const char *uploadpack = NULL;
 	const char **pattern = NULL;

@@ -67,6 +68,10 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
 				flags |= REF_NORMAL;
 				continue;
 			}
+			if (!strcmp("--quiet", arg) || !strcmp("-q", arg)) {
+				quiet = 1;
+				continue;
+			}
 			usage(ls_remote_usage);
 		}
 		dest = arg;
@@ -99,6 +104,9 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
 	ref = transport_get_remote_refs(transport);
 	if (transport_disconnect(transport))
 		return 1;
+
+	if (!dest && !quiet)
+		fprintf(stderr, "From %s\n", *remote->url);
 	for ( ; ref; ref = ref->next) {
 		if (!check_ref_type(ref, flags))
 			continue;
diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index 3cf1b3d..d191235 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -57,12 +57,24 @@ test_expect_success 'dies when no remote specified and no default remotes found'

 test_expect_success 'use "origin" when no remote specified' '

-	git remote add origin "$(pwd)/.git" &&
-	git ls-remote >actual &&
+	URL="$(pwd)/.git" &&
+	echo "From $URL" >exp_err &&
+
+	git remote add origin "$URL" &&
+	git ls-remote 2>actual_err >actual &&
+
+	test_cmp exp_err actual_err &&
 	test_cmp expected.all actual

 '

+test_expect_success 'suppress "From <url>" with -q' '
+
+	git ls-remote -q 2>actual_err &&
+	test_must_fail test_cmp exp_err actual_err
+
+'
+
 test_expect_success 'use branch.<name>.remote if possible' '

 	#
@@ -78,10 +90,14 @@ test_expect_success 'use branch.<name>.remote if possible' '
 		git show-ref	| sed -e "s/ /	/"
 	) >exp &&

-	git remote add other other.git &&
+	URL="other.git" &&
+	echo "From $URL" >exp_err &&
+
+	git remote add other $URL &&
 	git config branch.master.remote other &&

-	git ls-remote >actual &&
+	git ls-remote 2>actual_err >actual &&
+	test_cmp exp_err actual_err &&
 	test_cmp exp actual

 '
--
1.7.1.189.g07419
Junio C Hamano· May 12, 2010, 05:50 UTC · re: Tay Ray Chuan · lore

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

Tay Ray Chuan <rctay89@gmail.com> 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.

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?

Tay Ray Chuan· May 14, 2010, 03:07 UTC · re: Junio C Hamano · lore

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

Hi,
On Wed, May 12, 2010 at 1:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> Tay Ray Chuan <rctay89@gmail.com> 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.

Show 7 quoted lines
> 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
Jonathan Nieder· May 14, 2010, 16:17 UTC · re: Tay Ray Chuan · lore

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 <gitster@pobox.com> wrote:
Show 6 quoted lines
>> 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.
Show 8 quoted lines
> 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
Tay Ray Chuan· May 15, 2010, 09:56 UTC · re: Jonathan Nieder · lore

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

On Sat, May 15, 2010 at 12:17 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 16 quoted lines
> 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.

Show 18 quoted lines
>> 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
Jonathan Nieder· May 15, 2010, 16:20 UTC · re: Tay Ray Chuan · lore

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

Tay Ray Chuan wrote:
> On Sat, May 15, 2010 at 12:17 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 10 quoted lines
>> 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"?

It didn’t. I was just saying that it should (or we should provide some commands to that effect). What do you think?

Maybe later today... Jonathan

Junio C Hamano· May 20, 2010, 13:27 UTC · re: Jonathan Nieder · lore

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

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 16 quoted lines
> Tay Ray Chuan wrote:
>> On Sat, May 15, 2010 at 12:17 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
>>> 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"?
>
> It didn’t.  I was just saying that it should (or we should provide some
> commands to that effect).  What do you think?
I think you said what I meant to say much more clearly.  Thanks.
Geert Bosch· May 16, 2010, 02:14 UTC · re: Tay Ray Chuan · lore

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

On May 13, 2010, at 23:07, Tay Ray Chuan wrote:
Show 8 quoted lines
>> 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.

What git seems to be missing is a "git info" command, which would print out essentially something like what "svn info" does: name of remote repo that we're tracking, name of current branch, date/author/subject of last commit.

Regards,
  -Geert
Sverre Rabbelier· May 16, 2010, 10:36 UTC · re: Geert Bosch · lore

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

Heya,
On Sun, May 16, 2010 at 04:14, Geert Bosch <bosch@adacore.com> wrote:
> What git seems to be missing is a "git info" command, which
> would print out essentially something like what "svn info" does:
> name of remote repo that we're tracking, name of current branch,
> date/author/subject of last commit.
You can get information about the remote with:
$ git remote -v
And then for the branch etc you can do (although it doesn't list the author):
$ git branch -v
-- 
Cheers,

Sverre Rabbelier
Geert Bosch· May 16, 2010, 17:27 UTC · re: Sverre Rabbelier · lore

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

On May 16, 2010, at 06:36, Sverre Rabbelier wrote:
Show 9 quoted lines
> On Sun, May 16, 2010 at 04:14, Geert Bosch <bosch@adacore.com> wrote:
>> What git seems to be missing is a "git info" command, which
>> would print out essentially something like what "svn info" does:
>> name of remote repo that we're tracking, name of current branch,
>> date/author/subject of last commit.
> 
> You can get information about the remote with:
> 
> $ git remote -v
geert-boschs-computer:/tmp%ssh kwai git init --bare /work/bosch/temp.git
Initialized empty Git repository in /export/work/bosch/temp.git/
geert-boschs-computer:/tmp%git init temp
Initialized empty Git repository in /private/tmp/temp/.git/
geert-boschs-computer:/tmp%cd temp
geert-boschs-computer:/tmp/temp%echo hello>world
geert-boschs-computer:/tmp/temp%git add world
geert-boschs-computer:/tmp/temp%git commit -m "Add hello" world
[master (root-commit) 10837b9] Add hello
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 world
geert-boschs-computer:/tmp/temp%git push --all kwai:/work/bosch/temp.git
Counting objects: 3, done.
Writing objects: 100% (3/3), 211 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To kwai:/work/bosch/temp.git
 * [new branch]      master -> master
geert-boschs-computer:/tmp/temp%git push -u --all kwai:/work/bosch/temp.git
Branch master set up to track remote branch master from kwai:/work/bosch/temp.git.
Everything up-to-date
geert-boschs-computer:/tmp/temp%git remote -v
geert-boschs-computer:/tmp/temp%git push
Everything up-to-date

So, there is a remote that gets used automatically by git push and git pull, but it's not obvious which one. Basically, a "git info" command should give a dozen lines or so that allows one quickly to identify a repository, including current branch, any remote it tracks, last commit, wether the working directory is clean, wether anything is staged for commit, wether the repository tracks a non-git (svn, bzr, hg) repository.

> 
> And then for the branch etc you can do (although it doesn't list the author):
> 
> $ git branch -v

While both commands are very useful, I think a case can be made for a single command that pulls together enough information in a few lines that it is clear.

I'll see if I can cobble something up.

← back to recent threads