Excluding some refspecs from git push?

Excluding some refspecs from git push?

[Paul Sokolovsky]

Hello,

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

Re: Excluding some refspecs from git push?

[Shawn Pearce]

On Sat, Jul 23, 2011 at 14:46, Paul Sokolovsky
<paul.sokolovsky@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.

Re: Excluding some refspecs from git push?

[Magnus Bäck]

On Sunday, July 24, 2011 at 21:19 CEST,
     Shawn Pearce <sop@google.com> wrote:

> On Sat, Jul 23, 2011 at 14:46, Paul Sokolovsky
> <paul.sokolovsky@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

Re: Excluding some refspecs from git push?

[Shawn Pearce]

On Sun, Jul 24, 2011 at 12:32, Magnus Bäck <magnus.back@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.

>> 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.)