问题
I asked a question recently about the mechanism for mirroring into gerrit, but I'm starting to think that perhaps that's not an ideal thing to do (useful to know but maybe not for this use case). This question builds upon that one.
There's a project on github we'd like to work on, and we'd like to see the branches for. We'd manage this with gerrit. I want to see the branches (and tags) but I don't want to check out directly on the remote branches... we'll have our own local branches and tags.
Currently I can mirror such a repo into gerrit, such that it appears exactly like a clone of the repository, with branches and tags in place (e.g., branch foobar remains foobar locally, not origin/foobar or remotes/origin/foobar). However, it appears that having the remote refs stay origin/foobar or such might be preferable (and more in line with how this is generally done).
So, is mirroring an external project into a local gerrit (such as above) in any way preferable to cloning it in a way that allows its remote branches to stay "remote"? Does having the remote refs pointing to origin/foobar instead of foobar matter, if we're never wanting to check out directly on those remote branches? Finally, where I'd expect to see origin/foobar on a non-mirror clone I'm seeing remotes/origin/foobar... what might I be doing wrong there? (I also lose the benefits of bare mirroring with clone, so that seems a poor option regardless.)
Note: the suggestion to use fetch is helpful as a way to populate a bare local repo (I fleshed out the detailed process in my original question, as an alternative to using --mirror).
I'll add that I'm now aware of a related question. Perhaps I'm overthinking the "remotes" thing in particular, but the question of mirror or clone remains - people will be working based on tags and local, uniquely named branches, not remotes. I'd like to strenuously avoid naming conflicts that could arise internally as well, so knowing how to do this optimally is not simply academic.
回答1:
I don't use gerrit, but I'd recommend leaving the remote branch names be. Branches are pointers, and there's nothing particularly special about their namespace. If you renamed the remote's branches to be, say, origin/foo instead of foo, when you tracked it locally you'd end up tracking origin/origin/foo. The specification locally is <remote>/<remote_branch>. It's confusing, and won't prevent operations like git checkout defaulting to origin/foo locally when creating local tracking branches.
Instead of making things more clear and less prone to error, the scheme would complicate them and make errors quite easy.
In my experience, naming conflicts are a workflow problem, not a git problem. For example, we generally encourage our devs to use case-ID based names, and all branches whether case-ID'd or not are prefaced by the initials of the author (mm/3245 or mm/gerrit-mirroring-code). We stole this convention from the git project itself. We haven't suffered a collision after a year of use (and nearly 1000 feature branches). In the rare case where two identically-named but totally different branches were being pushed to the same remote, git would reject the push anyway, as the update wouldn't fast-forward.
回答2:
Hopefully others chime in.
The simplest solution to this seems to be NOT to mirror but to simply make a new local clone, then push it to gerrit adding "refs/*:refs/*" to the end of the push command, so as to ensure the remote refs end up in gerrit's repo.
At that point you can see the remote refs if you look at the gerrit git repo itself (but not in the web UI, which is fine... we don't want to directly merge to them in this effort).
A developer can then clone the repo from gerrit (or a clone of it) to do work. TO see the remote branch refs though, they need to take the extra step of fetching the refs, thus:
git fetch origin refs/remotes/*:refs/remotes/*
Then they can see the remotes as well as everything else.
If you do all this by starting with a mirror, the external refs are brought in as-is (not as remotes), and the external branches appear in the gerrit web UI as if you put them there. That has its own uses, but for what I'm doing it would not be helpful.
来源：https://stackoverflow.com/questions/12398700/initializing-a-local-git-gerrit-repository-whats-the-optimal-way-to-do-this