threads / discuss / 27901

Excluding some refspecs from git push?

Subject: Excluding some refspecs from git push?

## tl;dr

4 messages between Jul 23, 2011 and Jul 24, 2011.

replies: 3people: 3as markdown or json

Paul Sokolovsky· Jul 23, 2011, 21:46 UTC · lore

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

Shawn Pearce· Jul 24, 2011, 19:19 UTC · re: Paul Sokolovsky · lore

Re: Excluding some refspecs from git push?

On Sat, Jul 23, 2011 at 14:46, Paul Sokolovsky <paul.sokolovsky@linaro.org> wrote:

Show 11 quoted lines

> 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· Jul 24, 2011, 19:32 UTC · re: Shawn Pearce · lore

Re: Excluding some refspecs from git push?

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

Show 19 quoted lines

> 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

Shawn Pearce· Jul 24, 2011, 19:45 UTC · re: Magnus Bäck · lore

Re: Excluding some refspecs from git push?

On Sun, Jul 24, 2011 at 12:32, Magnus Bäck <magnus.back@sonyericsson.com> wrote:

Show 8 quoted lines

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

Show 7 quoted lines

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