how to fetch the remote repository of a remote repository which is not checked out in git

Question

Is there a way to fetch the remote repository of a non-checked-out remote repository with git?

I have the dotfiles on my remote PC under version control (using yadm). This repository is cloned on my local PC (also using yadm). But on my local PC I'm using a different dotfiles management utility (rcm) which allows for more flexibility.

Since yadm and rcm work on a different basis (symlinks to ~ vs. bare git into ~) I have to jump through hoops to try stuff using yadm on my local PC:

• unlink my current symlink-dotfiles with rcm
• checkout the yadm-repository

To undo that I then have to

• remove all the files which were cloned when checking out the yadm-repository
• symlink the files with rcm

This is annoying. Therefore I cloned the local clone of my yadm-repository into a different folder. While I'm able to see all the remotes in my local main yadm-repository, I'm only able to fetch HEAD in the cloned yadm-repository.

It looks like that:

remote PC (1):                    commit a (old, not checked out), commit b (HEAD -> master)
local  PC - main repository (2):  commit a (HEAD -> master), commit b (origin/master, not checked out)
local  PC - other repository (3): commit a (HEAD -> master), commit a origin/master

So on my repository 3 I'm only able to see the commit a (which is checked out in repository 2), but not commit b (which is not checked out in repository 2, but should be available there). My question is now: how can I get commit b in my repository 3 and why doesn't that work by just git fetching everything?

---

Update 1: Minor edits to the text were performed to (hopefully) make the issue clearer.

Answer 1

Since each of the repositories are not bare repositories, at least where it matters, they are not. Therefore, the default behavior seems to be what has been observed, i.e., repository 3 only sees the checked-out commit of repository 2.

To override this behavior, git fetch has an optional refspec argument which can be used to specifically fetch the other revision. Mapping this to a different branch will likely make this a bit easier.

git fetch origin b

Or since origin/master points to commit b, using origin/master as the refspec should also work:

git fetch origin origin/master

Again, having commit b on a branch or tag would likely make this fetch easier. If that is not the case, it's necessary to perform the merge by manually specifying the hash of the commit (although it will not be visible using git log --all).