cherry-picking gerrit patch - am i doing it right?

[Vicki Kozel]

Hello,

we had a bunch of dependent changes collected in our gerrit. These changes were not very new and were made to the files that are actively modified all the time. The way I would try and merge the older change to a master would be:

1. make sure my local master is up-to-date with the central one.

2. copy a cherry-pick command from the change page on Gerrit server:

git fetch ssh://gerrit:29418/MyApp refs/changes/85/385/2 && git cherry-pick FETCH_HEAD

and execute this command from the master branch

3. This would put the commit from the older change on top of my master.

4. git commit --amend  -will open the commit editor and I would copy a change ID of the change in question as a comment.

5. push to gerrit. (all successfully merged)

My question is - does cherry-pick do a merge? Would it complain about merge conflicts in case conflicts are present? Or is it just forcing the cherry-picked commit on top of other commits and overrides previous changes?

Thank you,

Vicki

[David Pursehouse]

On 11/21/2013 10:10 AM, Vicki Kozel wrote:
> Hello,
> we had a bunch of dependent changes collected in our gerrit. These
> changes were not very new and were made to the files that are actively
> modified all the time. The way I would try and merge the older change to
> a master would be:
>
> 1. make sure my local master is up-to-date with the central one.
> 2. copy a cherry-pick command from the change page on Gerrit server:
>
> git fetch ssh://gerrit:29418/MyApp refs/changes/85/385/2 && git
> cherry-pick FETCH_HEAD
>
> and execute this command from the master branch
>
> 3. This would put the commit from the older change on top of my master.
>

All seems OK so far.

> 4. git commit --amend -will open the commit editor and I would copy a
> change ID of the change in question as a comment.
>

You only need to do this if the change you're cherry-picking does not
already have a Change-Id line in the commit message.

If there is no Change-Id line you can push to 'refs/changes/12345'
(where 12345 is the actual change number). Then Gerrit does not need
the Change-Id line and you don't need to amend the commit message.

Also, be aware that the '--amend' option will cause problems if the
cherry-pick failed. See below.

>
> 5. push to gerrit. (all successfully merged)
>
> My question is - does cherry-pick do a merge? Would it complain about
> merge conflicts in case conflicts are present? Or is it just forcing the
> cherry-picked commit on top of other commits and overrides previous changes?
>

It does not do a merge as in "git merge". It will try to apply the
change on top of the head of the local branch, and if there are
conflicts it will fail.

In that case you can see the conflicting files with "git status". Edit
the files, resolve the conflicts, add them with "git add", and then
commit with "git commit".

Do NOT use "git commit --amend" when fixing a failed cherry-pick. This
is a common mistake and will result in the cherry-picked commit being
amended into the commit at the head of your local branch, rather than
being a new commit on top of the head.

Also note that the conflicting files will be listed at the bottom of the
commit message. This list appears after the existing "Change-Id" line
and thus will cause Gerrit to not recognise the Change-Id when you push
the change to 'refs/for/master'. Either remove the "conflicts" list,
move the Change-Id line below it, or push explicitly to
'refs/changes/12345' as mentioned above.

[Vicki Kozel]

David, thank you very much for your answers. Mainly I wanted to make sure that if there are conflicts they would show up during the cherry pick with the same assertiveness as they do during merge or rebase (so I'd be blocked from proceeding with a commit, etc). I was not even aware that you can fix a failed cherry-pick. Cherry-picks fail for us when use them for merge commits if these commits have two parents. Is there a work around for this?

Thank you.

Vicki

[David Pursehouse]

On 11/22/2013 04:09 AM, Vicki Kozel wrote:
> David, thank you very much for your answers. Mainly I wanted to make
> sure that if there are conflicts they would show up during the cherry
> pick with the same assertiveness as they do during merge or rebase (so
> I'd be blocked from proceeding with a commit, etc). I was not even aware
> that you can fix a failed cherry-pick. Cherry-picks fail for us when use
> them for merge commits if these commits have two parents. Is there a
> work around for this?
>

There's a good answer for this on stack overflow [1].

You're probably better off re-doing the merge and uploading a new commit
rather than trying to cherry-pick it.


[1]
http://stackoverflow.com/questions/9229301/git-cherry-pick-says-38c74d-is-a-merge-but-no-m-option-was-given