[asterisk-dev] Git Migration

[Paul Belanger]

On Thu, Sep 18, 2014 at 5:12 PM, Russell Bryant
<russell at russellbryant.net> wrote:
> On Thu, Sep 18, 2014 at 3:01 PM, Samuel Galarneau <sgalarneau at digium.com>
> wrote:
>>>
>>>
>>> A couple more comments about the magic happening here ...
>>>
>>> First, "git review" knows where to push based on a file checked in to the
>>> repo:
>>>
>>>  $ cat .gitreview
>>> [gerrit]
>>> host=review.openstack.org
>>> port=29418
>>> project=openstack/nova.git
>>>
>>> "git review" also sets up a local commit hook that adds a "Change-Id"
>>> header to your commit message.  That Change-Id is what links multiple
>>> revisions of the same change together.  So, if you edit your change and push
>>> it again, as long as the Change-Id remains the same, gerrit treats it as the
>>> same review request and not a new one.
>>
>>
>> Sounds good to me. So it doesn't really matter from which repo you post a
>> review so long as it's a clone of the original with that .gitreview file.
>>
>> I have another question unrelated to reviews. Does your setup make it easy
>> to mirror a repo? In a more complicated scenario, what if someone had a
>> private fork but they wanted to get public commits to master mirrored to
>> their repo? Would they have to treat the original repo as upstream and
>> manually pull changes and rebase their private branch off of it?
>
>
> Mirroring, sure.  I don't remember exactly how we do it, but all OpenStack
> repos are mirrored to github for convenience, for example.
>
Technically, the repos on github for Openstack are the mirrors of a
mirror, I know :)

The basic idea is the upstream repo lives either in gerrit or zuul,
then can mirror the repos to any system. Thing to remember, everything
goes through gerrit and zuul.  So, if you mirrored to github, PR are
useless since it is only read-only.

For internal projects, I host a cgit server and public I just mirror to github.

> Regarding private branches, git generally makes that kind of thing
> ***MUCH*** easier than svn.  You can easily track the exact commits that are
> applied on top of upstream.  You could either periodically rebase your
> changes on top of upstream (re-applying the commits, rewriting history but a
> cleaner history), or periodically merge from upstream.  In either case, I
> personally wouldn't automate it.  You want some sanity checking around that
> stuff.  Conflicts happen.  Really, I think this is going to be MUCH better
> no matter what specific infrastructure you go with.
>
> --
> Russell Bryant
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev



-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger