[asterisk-dev] git migration update

[Matthew Jordan]

On Mon, Dec 22, 2014 at 9:01 PM, Tzafrir Cohen <tzafrir.cohen at xorcom.com> wrote:
>
> Hi,
>
> Thanks for the update.
>
> On Mon, Dec 22, 2014 at 01:03:17PM -0600, Samuel Galarneau wrote:
> > Just wanted to update everyone on the git migration status and illicit some
> > feedback on a few items.
> >
> > We setup an instance of Gerrit and Jenkins internally, imported the
> > Asterisk testsuite into a git repo, and configured Gerrit and Jenkins
> > together.
>
> Just a note: currently we have two pending "reviews" of patches by
> private mails in dahdi: one in dahdi-linux and one in dahdi-tools. I
> wonder when we can start using Gerrit.
>
> >
> > 2 - we have a few options as far as team branches go. We could configure
> > user branches using refs/heads/team/${username}/* permissions in Gerrit to
> > allow users to create branches. This would prohibit other users from
> > pushing to a user branch, but they would still be visible. This would most
> > likely involve reproducing some sort of automerge/autorebase process. The
> > other option is to use github as another remote for team branches, with a
> > remote pointing to Gerrit for code reviews. Is there a preference between
> > these two approaches, or perhaps a better setup we could follow?
>
> What if I have my own git server (which is not github)?
>
> But then again, why are team branches needed? When I work on my own
> branch I keep it in sync with the main development branch manually. If I
> don't work on it, it will fall back, but merging the changes (or
> rebasing) should be easy with git. And if I want to work on someone
> else's branch I can do this sync on my own.
>
> I don't think I'd want automerge. Autorebase is probably bad as you
> can't clone that branch. If I rebase a branch I'd like to decide when it
> is done.
>

So this point - is automerge necessary or not - is a large portion of
what prompted Sam's original e-mail. In exploring git and our existing
workflow, the automerge script itself turned out to be rather tricky.
As he pointed out in his first comment, merely re-building the history
from the various automerge properties has some complexity. The
automerge script has its own complexities - should we be automatically
rebasing branches? Should it instead cherry-pick commits? Neither
option is terribly attractive, for different reasons.

My inclination is that we won't know if we really need a git version
of the automerge script until we've used git for awhile. I suspect
that you are right, and that manually rebasing a branch is not much
additional work (if any) over what is already required when using
automerge.

I'd propose that, at the very least, we ignore the automerge script
portion of team branches until we know if we need it.

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org