Merging between branches with gerrit

[Sean]

I've created a release branch in gerrit (let's call it release-1.0).
Now, I want to merge some changes from master to the release branch,
so I do:
banana% git checkout -b release origin/release-1.0
banana% git cherry-pick <change>
banana% git push origin HEAD:refs/for/release-1.0

Unfortunately, since this change has a Change-Id, it doesn't show up
in gerrit. I assume that's because gerrit sees the Change-Id as
already having been submitted to master. Is there something wrong
with my process? Is there any way other than manually changing or
removing the Change-Ids to get gerrit to recognize the new changes?

[Magnus Bäck]

On Friday, July 15, 2011 at 07:02 CEST,
Sean <sean....@gmail.com> wrote:

> I've created a release branch in gerrit (let's call it release-1.0).
> Now, I want to merge some changes from master to the release branch,
> so I do:
> banana% git checkout -b release origin/release-1.0
> banana% git cherry-pick <change>
> banana% git push origin HEAD:refs/for/release-1.0

Technically, that's a cherry-pick and not a merge -- two very
different things with Git.

> Unfortunately, since this change has a Change-Id, it doesn't show up
> in gerrit. I assume that's because gerrit sees the Change-Id as
> already having been submitted to master. Is there something wrong
> with my process? Is there any way other than manually changing or
> removing the Change-Ids to get gerrit to recognize the new changes?

I'm afraid you'll have to remove the Change-Id line to have
a new one generated by the commit message hook. You could also
use the "repo cherry-pick" command added in Repo 1.7.4.3. It does
that for you.

https://review.source.android.com/20371

--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson

[Sean Soria]

Thanks for the pointer to repo.  I was actually doing "git merge origin/master" but I figured it would be just as relevant if I was cherry-picking individual changes.  Is there a repo merge command as well?

--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

[Sean Soria]

And where can I download repo?

[Magnus Bäck]

On Friday, July 15, 2011 at 20:17 CEST,
Sean Soria <sean....@gmail.com> wrote:

> Thanks for the pointer to repo. I was actually doing "git merge
> origin/master" but I figured it would be just as relevant if I was
> cherry-picking individual changes.

If you want to use Git's history traversal features to track where
corrections have been made it's less fun when fixes have been
cherry-picked. It can't always avoided, but there are branching
patterns that'll prefer merges over cherry-picks.

> Is there a repo merge command as well?

No. I don't see a need for such a command.

[Magnus Bäck]

On Friday, July 15, 2011 at 20:20 CEST,
Sean Soria <sean....@gmail.com> wrote:

> And where can I download repo?

The bootstrapper script can be obtained from [1], see [2], but the
part of Repo that actually does something is automatically downloaded
and upgraded when you run "repo sync" in a Repo-maintained workspace.
Chances are you already are running the latest version.

[1] https://android.git.kernel.org/repo
[2] http://source.android.com/source/downloading.html

[Sean Soria]

Merging seems to cause the same issues as before.  I get a series of commits to the merged to branch which all have the same Change-Id as their original commits, and thus, when I push to gerrit (which knows about both branches), the changes get lost.  Isn't this a good use case for a repo merge?

[Magnus Bäck]

On Friday, July 15, 2011 at 23:26 CEST,
Sean Soria <sean....@gmail.com> wrote:

> Merging seems to cause the same issues as before. I get a series of
> commits to the merged to branch which all have the same Change-Id as
> their original commits, and thus, when I push to gerrit (which knows
> about both branches), the changes get lost. Isn't this a good use
> case for a repo merge?

When you do a merge, the old commits will be reused. This is expected
and actually desireable. Why would you want to review old commits again
just because they appear on a new branch? When merging two branches the
only commit that will be reviewed is the merge commit (which will appear
empty).

[Sean Soria]

So the workflow you're suggesting is that the person doing merges has push access directly to the merged to branch?

[Magnus Bäck]

On Saturday, July 16, 2011 at 11:48 CEST,
Sean Soria <sean....@gmail.com> wrote:

> On Fri, Jul 15, 2011 at 11:16 PM, Magnus Bäck
> <magnu...@sonyericsson.com>wrote:
>

> > When you do a merge, the old commits will be reused. This is
> > expected and actually desireable. Why would you want to review old
> > commits again just because they appear on a new branch? When merging
> > two branches the only commit that will be reviewed is the merge
> > commit (which will appear empty).
>

> So the workflow you're suggesting is that the person doing merges has
> push access directly to the merged to branch?

No, not necessarily. Merge commits can be uploaded for review just
like any other commit. A code review approval of such a commit can
be interpreted as "yes, it's okay to make this merge onto this branch".