Are conflicts unavoidable when cherry picking a commit?
https://stackoverflow.com/questions/11759953
-
24-06-2021 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
I am working on a code and I found my self in a situation similar to one explained on this blog. Basically, I have two versions of the code, that use completely different containers. This is done to compare the efficiency of the code when different containers are used. Because I am relying on the efficient container member functions, I cannot make the code generic with respect to containers, so I chose an approach where I have two git branches: one for optimized code and the other for not optimized code.
The problem is that after I have optimized a part of the code, I need to do some common work on two, now diverging, branches. Is it possible to do the work on an "upstream" (non-optimized) branch and then cherry pick the common commits to the optimized branch without resolving a lot of conflicts?
I have followed the tutorials found online, created a dummy repository with a single file (to test the conflicts) and some branches.
For this git repository example, is it possible to cherry pick say commit "02 second" on the branch "second" into the master branch without resolving conflicts? I have nothing against conflict resolving, but I am interested if it could be avoided.
What is the correct workflow in this situation? Should I apply changes that are common, commit, cherry pick + resolve conflicts, and that's it?
Soluzione
Commits are Patch Sets
Cherry-picking doesn't inherently introduce conflicts. A lot has to do with how atomic your commits are. Think of a commit as a set of patches applied to a tree. If your patches do not overlap, then you can cherry-pick with impunity. On the other hand, if you have wide-ranging, overlapping, or complex commits, then a cherry-pick will generally contain more changes than you can smoothly apply.
Consider this:
# Patch A
Line one
Line two
Line three
# Patch B
Line one
Line 2
Line three
# Current HEAD
First line
Second line
Third line
With this contrived example (note: I didn't test it, I'm just using it to illustrate a point), trying to cherry-pick both A and B onto HEAD will probably not apply cleanly because the changes overlap. On the other hand, cherry-picking something like:
# Cherry-pick me from another branch!
First line
Second line
Third line
Fourth line
onto HEAD will introduce no conflicts, because there's no overlap.
Obviously, specific use cases may be different, but the general rule of thumb is that small, atomic commits are ripe for cherry-picking, while "big ball of mud" commits are usually problematic. YMMV.
