Excluding some refspecs from git push?
Paul Sokolovsky
Is there a way to exclude some refspec from being processed by "git
push"? What I'm looking for is a syntax like:
push some-remote 'refs/*' '!refs/meta/config'
, with the meaning of "push all refs except refs/meta/config". What I'm
trying to do with this is to find out a generic way to mirror git
repositories managed by the Gerrit tool
(http://code.google.com/p/gerrit/), which since version 2.2 uses
refs/meta/config branch to store repository-local configuration, so
should not be mirrored between two Gerrit's.
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Shawn Pearce
<paul.so...@linaro.org> wrote:
> Is there a way to exclude some refspec from being processed by "git
> push"? What I'm looking for is a syntax like:
>
> push some-remote 'refs/*' '!refs/meta/config'
>
> , with the meaning of "push all refs except refs/meta/config". What I'm
> trying to do with this is to find out a generic way to mirror git
> repositories managed by the Gerrit tool
> (http://code.google.com/p/gerrit/), which since version 2.2 uses
> refs/meta/config branch to store repository-local configuration, so
> should not be mirrored between two Gerrit's.
Unfortunately no. But you should be able to just mirror the namespaces
that matter:
refs/heads/*
refs/tags/*
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.
Magnus Bäck
Shawn Pearce <s...@google.com> wrote:
> On Sat, Jul 23, 2011 at 14:46, Paul Sokolovsky
> <paul.so...@linaro.org> wrote:
> > Is there a way to exclude some refspec from being processed by "git
> > push"? What I'm looking for is a syntax like:
> >
> > push some-remote 'refs/*' '!refs/meta/config'
> >
> > , with the meaning of "push all refs except refs/meta/config". What
> > I'm trying to do with this is to find out a generic way to mirror
> > git repositories managed by the Gerrit tool
> > (http://code.google.com/p/gerrit/), which since version 2.2 uses
> > refs/meta/config branch to store repository-local configuration, so
> > should not be mirrored between two Gerrit's.
>
> Unfortunately no. But you should be able to just mirror the namespaces
> that matter:
>
> refs/heads/*
> refs/tags/*
Any reason to omit refs/notes/*?
> 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?
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
Shawn Pearce
>>
>> 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.)
Paul Sokolovsky
On Sun, 24 Jul 2011 12:45:20 -0700
Shawn Pearce <s...@google.com> wrote:
> On Sun, Jul 24, 2011 at 12:32, Magnus Bäck
> <magnu...@sonyericsson.com> 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.
Thanks. The reason I wanted to mirror everything is exactly because I
didn't know what may be needed, so used black-box logic with "all
except known unneeded".
>
> >> 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.
I figured all those issues on practice ;-(. It indeed took long time to
push single mirrored git repo, and it ended with "failed to lock" for
each refs/changes/*, and while I initially thought it's good idea to
mirror changes, second thought was that sequential number may/will lead
to conflicts on a different server. Will go figure how to clean it up
now ;-).
> 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.)
Yes, I thought it's a bit of discrepancy that Gerrit even in web UI
shows hash-based change ids, but uses sequential numbers in URLs.