Skip to contentSkip to conversation

Git.pm: Add remote_refs() git-ls-remote frontend

PATCH In review Petr Baudis 2 participants 3 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Git.pm: Add remote_refs() git-ls-remote frontend

Should support all the important features, I guess. Too bad that

	git-ls-remote --heads .

is subtly different from

git-ls-remote . refs/heads/

so we have to provide the interface for specifying both.

This patch also converts git-svn.perl to use it.

---

 git-remote.perl |    5 +----
 perl/Git.pm     |   55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 55 insertions(+), 5 deletions(-)
git-remote.perl +1 -4
index 5763799..5403d86 100755
@@ -128,10 +128,7 @@ sub update_ls_remote {
 	return if (($harder == 0) ||
 		   (($harder == 1) && exists $info->{'LS_REMOTE'}));
 
-	my @ref = map {
-		s|^[0-9a-f]{40}\s+refs/heads/||;
-		$_;
-	} $git->command(qw(ls-remote --heads), $info->{'URL'});
+	my @ref = keys %{$git->remote_refs($info->{'URL'}, [ 'heads' ])};
 	$info->{'LS_REMOTE'} = \@ref;
 }
 
perl/Git.pm +54 -1

67 lines not on this page · raw message

#1 lore raw
Quoted 9 lines · Petr Baudis

.... Too bad that

	git-ls-remote --heads .

is subtly different from

git-ls-remote . refs/heads/

so we have to provide the interface for specifying both.

I've already heard you say the above elsewhere, but I am not sure what you exactly mean here. Mind substantiating it a bit more clearly?

I think "ls-remote --heads ." is just a special case of giving "refs/heads/*" as the glob pattern:

        $ git ls-remote --heads . | head -n 3
        3545193735522f733fdb4e345f16ddf131e2007a	refs/heads/ap/ident
        b7993dd57a9cfd5b989f0e2cc5d271a524339318	refs/heads/db/remote
        960ccca6803c9fb57429d43572a9545a96107e32	refs/heads/dh/pack
	$ git ls-remote . refs/heads/ | wc -l
        0
	$ git ls-remote . "refs/heads/*" | head -n 3
        3545193735522f733fdb4e345f16ddf131e2007a	refs/heads/ap/ident
        b7993dd57a9cfd5b989f0e2cc5d271a524339318	refs/heads/db/remote
        960ccca6803c9fb57429d43572a9545a96107e32	refs/heads/dh/pack
	$ git ls-remote . "refs/heads/???/*"
        7841ce79854868eaaa146c1d018b17fc4f3320be	refs/heads/mst/connect
        $ git ls-remote . "refs/*/jc/*" | head -n 4
        80a767ba3b1c69fc41fa5f5fbe4a247757a9c575	refs/heads/jc/blame
        a1481ab7b16c51d4ec7925fd9b38d9cf21f72263	refs/heads/jc/diff
        4e8daa0dca5deb9d391538241939a2a2ad6d36b8	refs/tags/hold/jc/3way
        ff77ab7919e6f31cb6c58bc004217e624b553fb6	refs/tags/hold/jc/changes

So if you really do not want separate interfaces, I think you could just implement --heads as what it is: a shorthand for "refs/heads/*".

#2 lore raw
Quoted 8 lines · Junio C Hamano
Quoted 6 lines · Petr Baudis

.... Too bad that

	git-ls-remote --heads .

is subtly different from

Quoted 7 lines
Quoted 3 lines

git-ls-remote . refs/heads/

so we have to provide the interface for specifying both.

I've already heard you say the above elsewhere, but I am not sure what you exactly mean here. Mind substantiating it a bit more clearly?

Because the arguments are matched like

	case "/$path" in
	*/$pat )

so if you have remote "refs" and refs/remote/refs/heads/x, git-ls-remote refs/heads/ is ambiguous. OTOH, --heads always match start of the path.

It's somewhat obscure and probably doesn't really matter for user interface, but API should be free even of obscure misbehaviour, I believe.

Signature · 4 lines
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett