Open Stack

On 2016-03-25 09:14:27 -0400 (-0400), Doug Hellmann wrote:
> OK. It looks like it grabs the tagged commit from the stable branch
> and merges that back into master, expecting the results to be null
> because we backport all changes to stable branches and don't introduce
> anything new there. Is that right?

Not quite. Read the git-merge(1) bit about its "ours" merge strategy
(the -s/--strategy option we're passing in that script):

    This resolves any number of heads, but the resulting tree of the
    merge is always that of the current branch head, effectively
    ignoring all changes from all other branches. It is meant to be
    used to supersede old development history of side branches. Note
    that this is different from the -Xours option to the recursive
    merge strategy.

So it effectively allows us to merge in the missing Git history
(making the tag appear in master's branch history) without changing
the contents of any files on master. The actual contents of the
stable source branch and master target branch are irrelevant, since
we're telling git merge to ignore that completely.

> I think having the tags merged like that is going to confuse reno,
> because I didn't expect us to be introducing a tag into the master
> history that wasn't actually there. I'll have to experiment with
> this to see if it really is a problem.

Hopefully it's no different than if the tag already appeared in
multiple branches because of pre-dating the creation of a branch.
It's not actually pushing a new tag object and so no additional
release jobs are run by it. The result of this job is simply a merge
commit for review like any other change in Gerrit (albeit somewhat
confusing looking due to how Gerrit's UI chooses to represent the
conflict resolution in the merge, hence the somewhat verbose commit
message we include).
-- 
Jeremy Stanley