0

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.

Community
  • 1
  • 1
MartyMacGyver
  • 9,483
  • 11
  • 47
  • 67
  • Perhaps, but there is utility in bare clones for the purpose of the pull (see http://stackoverflow.com/questions/3959924/whats-the-difference-between-git-clone-mirror-and-git-clone-bare). My main question is one of structure: what should this look like preferably, a mirror or a clone? – MartyMacGyver Sep 13 '12 at 02:49
  • So you are really asking for me to evaluate public repo offerings for you at no cost to you? – Adrian Cornish Sep 13 '12 at 02:57
  • Not at all! I'm asking how this is normally done in general for what should be a common use case. I'm just trying to learn here. – MartyMacGyver Sep 13 '12 at 03:02
  • I think you do not understand the true nature of `git` a clone it a complete copy of the repository- - is it the `truth` of what is is up to you to decide – Adrian Cornish Sep 13 '12 at 03:07
  • I don't understand where the "evaluate repo offerings" thing came from. I get the complete copy thing, though, and that bare is better than clone for this sort of thing. I'm just trying to understand whether a mirror is generally preferable when it comes to branch naming. A mirror effectively creates tracking branches for all the remotes it has some benefits (you could check out right on those branches, locally) but it also has risks (maybe you never want a remote branch unexpectedly conflicting with a local branch of the same exact name). What's normally done to populate gerrit? – MartyMacGyver Sep 13 '12 at 03:13

2 Answers2

0

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.

Christopher
  • 42,720
  • 11
  • 81
  • 99
  • I'm not aiming to manually rename anything. The way you clone the external repo defines what the remote branches end up looking like... mirroring doesn't create remotes - the branch refs are automatically created as if they were local. Cloning bare and fetching the refs actually creates remotes for the remote branches (which *seems* to be more common since most people simply clone, but given that we're populating gerrit it may be preferable to choose a certain method e.g. mirroring vs clone bare + fetch). – MartyMacGyver Sep 13 '12 at 17:17
0

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.

MartyMacGyver
  • 9,483
  • 11
  • 47
  • 67