Thread (4 messages) flat view 4 messages, 3 authors, 2016-06-15

Re: Excluding some refspecs from git push?

From: Shawn Pearce <hidden>
Date: 2016-06-15 22:51:38

On Sun, Jul 24, 2011 at 12:32, Magnus Bäck [off-list ref] wrote:
quoted
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.
quoted
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.)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help