Is it possible to see a remote's remotes in git?

Question

I have a local git clone of a repo. I can of course see my local remote, origin using git remote. However, can I see the remotes for my remote, origin? Can I see any details about those remotes, such as the URL?

Answer 1

Not in general, other than via the method in the comment (ssh to the server and run git remote there).

You can, however, see all¹ of the remote's references, including its own remote-tracking branches, and from this information you can make some good guesses:

$ git ls-remote
From ssh:[redacted]
d1574b852963482d4b482992ad6343691082412f    HEAD
222c4dd303570d096f0346c3cd1dff6ea2c84f83    refs/heads/branch
d1574b852963482d4b482992ad6343691082412f    refs/heads/master
d1574b852963482d4b482992ad6343691082412f    refs/remotes/foo/bar
d41117433d7b4431a188c0eddec878646bf399c3    refs/tags/tag-foo

The above implies that the machine in question must have a remote named foo (from which it got branch bar, renamed to refs/remotes/foo/bar). In fact, it doesn't, as I created that remote-tracking branch manually just before this:

$ cd ~/tmp/t
$ git update-ref refs/remotes/foo/bar master
$ git for-each-ref
222c4dd303570d096f0346c3cd1dff6ea2c84f83 commit refs/heads/branch
d1574b852963482d4b482992ad6343691082412f commit refs/heads/master
d1574b852963482d4b482992ad6343691082412f commit refs/remotes/foo/bar
d41117433d7b4431a188c0eddec878646bf399c3 commit refs/tags/tag-foo

---

¹A remote can hide particular references now; you actually see only those they permit. The default is to permit all, though.

Bugs! Well, sort of.

Incidentally, along the way I discovered that git update-ref -d exits successfully even if it deletes nothing (I used git update-ref -d to delete refs/remotes/foo/bar but first ran it in wrong repo). This led to discovering another minor bug:

$ nullsha=0000000000000000000000000000000000000000
$ git update-ref -d refs/remotes/foo/bar $nullsha || echo bug

(no output, good: we "deleted" it successfully while expecting it not to exist in the first place).

$ git update-ref -d refs/remotes/foo/bar master && echo bug
error: cannot lock ref 'refs/remotes/foo/bar': unable to resolve
 reference refs/remotes/foo/bar: No such file or directory

Odd: the delete should (and did) fail as the ref does not exist, much less match master, but that's a pretty weird message. (Incidentally, I'm breaking up long lines for posting purposes.)

$ mastersha=$(git rev-parse master)
$ git update-ref -d refs/remotes/foo/bar $mastersha

Same failure message; seems like you can't provide a non-zero expected SHA1 and have a "quiet" failure. (The actual name-or-SHA-1 is irrelevant except that the all-zero "null hash" means "does not exist", as is generally the case in Git.)

What about creation, can we expect a null-hash to make sure we are the ones creating the ref?

$ git update-ref refs/remotes/foo/bar $mastersha $nullsha || echo bug

No output, good: it should create only if new, so let's try again and make sure the creation reports a nonzero status:

$ git update-ref refs/remotes/foo/bar $mastersha $nullsha && echo bug
fatal: update_ref failed for ref 'refs/remotes/foo/bar': cannot
 lock ref 'refs/remotes/foo/bar': ref refs/remotes/foo/bar is at
 11ae6ca18f6325c858f1e3ea2b7e6a045666336d but expected
 0000000000000000000000000000000000000000

No actual bug, but another odd message. This one at least makes sense though.

What happens if we ask to delete it, when we expect it to be deleted but it's not?

$ git update-ref -d refs/remotes/foo/bar $nullsha && echo bug
bug

Whoops, we were able to delete it! So don't try to use the null-hash for this purpose; there's no atomic-delete operation with the null hash, only atomic-create. (git update-ref -d correctly fails if we provide some other valid, but not $mastersha, hash; so atomic delete is a two-step operation: parse to get hash, then try to delete using that hash.)