3

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?

tmaric
  • 5,347
  • 4
  • 42
  • 75

1 Answers1

4

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.

See Also

Todd A. Jacobs
  • 81,402
  • 15
  • 141
  • 199
  • 1
    It doesn't sound like your use case, tomislav-maric, applies to this statement, but everything CodeGnome says here is even more pronounced if you ever want to merge those branches back together. Cherry-pick wreaks havoc on merging divergent, but heavily cross-picked branches. – Christopher Aug 01 '12 at 15:22