Monday, November 24, 2014

git merge

I'm so used to git merge doing the right thing re: merging files - and possibly used to working mostly by myself - that when git merge fails I always expect something messy has happened. However, just now, I got a merge complain that amounted to this:

from setuptools import setup, find_packages

setup(
      ... some things ...

<<<<<<< HEAD
    ext_modules=cythonize('lib/*.pyx'),
    entry_points={
      # Register the built in plugins
              ....
      # Command line scripts
              ....
    }
)
=======
    install_requires=
             ....
    cython_ext='lib/*.pyx'
)
>>>>>>> origin/fix_setup

I was surprised since the changes I made and my colleague made were simple and non-overlapping. They just need to come in sequence.

I took a look at the git merge documentation which said

When both sides made changes to the same area, however, Git cannot randomly pick one side over the other, and asks you to resolve it by leaving what both sides did to that area.

What happened here was that there were no intervening lines. We both appended our changes below "... some things ..." and above ")".

git merge's algorithm can't assume (rightly so) that these are tandem changes. Which should come first? Should they both be kept? And so on. It's not a mess, but it still takes humans - actually people working on the code - to figure out that, in this case, both should be kept, and it does not matter which comes first.


No comments:

Post a Comment