9

So I've created a git repository, set up some tags and remotes on my working copy, and then pushed the repository to my server with

git push --mirror my.remote.repository

Supposedly, pushing with git --mirror will also push the remotes that I've set up.

However, if I do

git clone my.remote.repository

I don't see the remotes that I created originally. Do I need special syntax to also clone the remotes? Does mirror not actually send remotes? Where did I go wrong?

Edit: Maybe my workflow is weird: Here's what I'm trying to accomplish. The repo is initially a clone of another project(A) that I don't control, where I've renamed the remote to 'upstream'. I've made a new 'master' branch, and intend to make changes to my working copy and deploy them. I will occasionally pull updates from the original repository (A) (switching to the original, unmodified branch and pulling from upstream). However, I'm working with other people, all of whom should be able to do this as well. The goal is to update the master branch with bug fixes from the initial repository(A) and commit the changes to the 'master' branch. Because of this, when a developer clones the repository, they should be inheriting the upstream branch so that they can actually do this. In short, I'm trying to use an 'upstream' branch to pull in updates from a different project. I haven't used a submodule to do this since the 'upstream' branch actually is responsible for 95% of the files in the repository and the entire project makes no sense without the files from upstream.

Zxaos
  • 7,791
  • 12
  • 47
  • 61
  • Perhaps I'm missing something, but if sounds as if you have a branch locally (called `foo`, say) which you are updating from `upstream/master`. Why don't you either just push that branch (as well as your `master`) to a bare repository that the other people can clone from? Or just let them clone your repository directly? In either case they'll get those branches as remote-tracking branches without using `--mirror` at any stage. – Mark Longair Oct 11 '11 at 21:27
  • @mark-longair Right, but those remote branches are tracking our own server instead of the upstream server they originally came from. While somewhat useful, it does mean that other people won't be (easily) able to pull updates from upstream(read-only) and then commit them to our own server (origin). – Zxaos Oct 12 '11 at 16:22
  • They can do that - they just need to add an extra remote that refers to the other repository. – Mark Longair Oct 12 '11 at 19:47
  • http://stackoverflow.com/questions/2248994/cloning-a-repository-without-making-it-the-origin-remote – Roberto Jan 06 '15 at 04:38

2 Answers2

2

(This isn't a typical workflow, but I'll try to answer the direct question anyway...)

git push --mirror will indeed have pushed your remote-tracking branches to the same name on the remote. However, when you clone, you by default only get the refs under refs/heads, which are mapped to remote-tracking branches under refs/remotes/origin/. You could clone with git clone --mirror to get the remote-tracking branches from the remote as well, but that option implies --bare.

If you want a repository with a working tree whose branches are mirrored from the remote, you could always change the refspec in the config option remote.origin.fetch to fetch every ref to the same name, but again I suspect that the real problem is that you're using a very unusual workflow.

Incidentally, even if you use one of those techniques to change the mapping of the refs that are fetched, this won't clone the remotes themselves, which are defined in the repository's git config - git clone doesn't clone anything from .git/config, which is considered to contain private information.

Mark Longair
  • 446,582
  • 72
  • 411
  • 327
  • I added some info about my workflow, in case that helps make this question make more sense. – Zxaos Oct 11 '11 at 20:04
  • So this looks like the way to do this. I should probably note, though, that I ended up just scrapping this workflow and using submodules instead. – Zxaos Oct 25 '11 at 21:56
  • This does not sound like an answer to the question, but the OP has moved on and accepted it anyway. How does editing the fetch setting for one remote automatically pull in the settings for another remote? – SensorSmith Aug 30 '18 at 16:04
  • It doesn't, but it helps with one aspect of what the OP wanted (mirroring the remote-tracking branches as well). The last paragraph addresses why git doesn't generally support cloning data like the remote settings. – Mark Longair Aug 30 '18 at 17:24
0

After cloning the repo, just copy the .git/config file which defines the remote URL:

git clone repo/ repo-clone/ && cp repo/.git/config repo-clone/.git/

Where repo/ and repo-clone/ are the source and destination folders.

sashoalm
  • 75,001
  • 122
  • 434
  • 781