Git Cherry-Pick and Conflicts

Question

There are two different git branches. In one the development is going in (Branch1).

In other branch some PoC work is going on (Branch2). Now, I want to cherry-pick the changes from Branch1 to Branch2, so that Branch2 is up to date.

Now, after cherry-picking 4 or 5 changes, I am getting some merge conflict and I am unable to proceed with further cherry-picks.

Do, I need to resolve all the conflicts before proceeding to next cherry -pick or Can I somehow postpone the conflict resolution till I cherry-pick all the changes (and resolve all conflicts together)?

Further, is it suggested to do cherry-pick or branch merge in this case?

Slime

One possible way to avoid these cherry-pick conflicts is by doing the cherry-picking in the order of oldest commit to latest commit, i.e. based on commit date. – Frayda

Answer 1

Do, I need to resolve all the conflicts before proceeding to next cherry -pick

Yes, at least with the standard git setup. You cannot cherry-pick while there are conflicts.

Furthermore, in general conflicts get harder to resolve the more you have, so it's generally better to resolve them one by one.

That said, you can cherry-pick multiple commits at once, which would do what you are asking for. See e.g. How to cherry-pick multiple commits . This is useful if for example some commits undo earlier commits. Then you'd want to cherry-pick all in one go, so you don't have to resolve conflicts for changes that are undone by later commits.

Further, is it suggested to do cherry-pick or branch merge in this case?

Generally, if you want to keep a feature branch up to date with main development, you just merge master -> feature branch. The main advantage is that a later merge feature branch -> master will be much less painful.

Cherry-picking is only useful if you must exclude some changes in master from your feature branch. Still, this will be painful so I'd try to avoid it.

Zedoary

Do you know if the inability to do this with standard git is an intentional design choice (and, if so, do you know why?), or just some accidental clumsiness? – Crackup

@LSpice: I do not know the design history of this feature, but I assume it was intentional. Git has a general convention of disallowing many things (such as a rebase) with an "unclean" workspace (i.e. with uncommitted changes). This generally simplifies the design of many commands, and avoids nasty special cases (such as how to handle conflicts). – Zedoary

Answer 2

Before proceeding:

• Install a proper mergetool. On Linux, I strongly suggest you to use meld:

  sudo apt-get install meld
  

• Configure your mergetool:

  git config --global merge.tool meld
  

Then, iterate in the following way:

git cherry-pick ....
git mergetool
git cherry-pick --continue

Toluidine

Answer 3

Also, to complete what @claudio said, when cherry-picking you can also use a merging strategy.

So you could something like this git cherry-pick --strategy=recursive -X theirs commit or git cherry-pick --strategy=recursive -X ours commit

Impressive

You just saved me a ton of time. Thanks – Florous