0

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.

Improve this question

1 Answer 1

Reset to default
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).

Improve this answer
5
  • Thanks for the answer - but this doesn't work... when adding the repository again and updating it I'm still only able to see the checked-out branch
    – n0542344
    Dec 18, 2020 at 21:55
  • Perhaps I'm not understanding the question. You want to pull hash b from repository A (first listed local repository) into repository B (second listed local repository)? Problem is A is not a bare repository and hash b is not on the HEAD of A, right? And you cannot pull hash b from the remote repository?
    – kballou
    Dec 19, 2020 at 21:58
  • I updated the question, hopefully it's clearer now. I have 3 repos available, repo 1 (original), repo 2 (a clone of repo 1) and repo 3 (a clone of repo 2). I can fetch everything into repo 2 (from repo 1) but don't want to check it out there. Then I'm fetching the content of repo 2 to repo 3, but there I'm unable to actually see the content of repo 1, I can only see what is checked out in repo 2.
    – n0542344
    Dec 20, 2020 at 1:38
  • I think that clarification helped. Hopefully, I'm getting it now; I have rewritten the answer.
    – kballou
    Dec 20, 2020 at 5:46
  • Awesome, thanks a lot! Just a minor comment: It's necessary to manually specify the commit (even it is not visible using git log --all) - I'll update your answer accordingly.
    – n0542344
    Dec 20, 2020 at 23:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .