On Sun, Jul 24, 2011 at 12:32, Magnus Bäck <magnus.back@xxxxxxxxxxxxxxxx> wrote: >> >> Unfortunately no. But you should be able to just mirror the namespaces >> that matter: >> >> refs/heads/* >> refs/tags/* > > Any reason to omit refs/notes/*? No, I forgot about refs/notes/*. You probably also want to mirror that. >> Its not a good idea to mirror refs/meta/config unless you want the >> same access controls, *AND ITS REALLY NOT A GOOD IDEA TO MIRROR >> refs/changes/* BETWEEN GERRIT SERVERS*. Yes, that last part is worth >> writing in full caps. > > Because of the excessive number of refs to advertise for a non-Gerrit > server, or what's the reason for the full caps? The excessive number of refs is a problem for any Git implementation (Gerrit included). But the all-caps warning is because of the way Gerrit uses these refs. Sometimes Gerrit scans the refs in a project, parses the change_id out of the reference name (e.g. refs/changes/42/1842/1 is change_id 1842) and then looks that change up in the database without matching the project name. This can cause strange results, like an ancient change in project Foo suddenly emailing its reviewers saying it has been merged into project SekretThing on branch NeverDiscloseThisToThatReviewerSet. We've had some pretty scary emails get sent out because of this matching. :-( Obviously this is a bug in Gerrit, when scanning the change_id data from the references, we should at least double-check the project names. But even with that check, two different Gerrit servers could both create change 1842 (as totally different changes) in the same project... e.g. if the servers each have exactly 1 project. Copying the refs from one server to the other may overwrite or at least confuse the destination's change data. Until the refs/changes/ namespace is modified to be more dependent upon Change-Id tokens and not the unique change_id sequence in the database, copying refs/changes/* between Gerrit servers is not a good idea. (Though it is OK if copied from a master to a slave, they share the same change database.) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html