We ran into an interesting issue yesterday during a rebase.
User Bob had added a line at the same place in a (C++) .h file as User
Joe, who had already pushed his one line change. The natural
expectation would be a conflict during User Bob's rebase operation, but,
in fact, the conflicting patch applied without difficulty.
After an investigation, we discovered this particular file had a near
duplicate of its C++ class definition immediately following the original
but renamed into a thread-safe version; the rename of the class was the
only change to its contents. The default 'git rebase' operation looked
some 150 lines into the file, discovered the patch didn't match due to
User Joe's added line, continued scanning the file until it found
another matching location some 300 lines later (the near duplicate
thread-safe version of the class), and applied the patch there.
While coming up with a repro to post here, we cherry picked the
individual changes and found the cherry pick properly conflicted.
We further discovered 'git rebase -m' (or 'git rebase -s recursive')
also conflicted at the User Bob/Joe modification.
I can post a repro here, if needed.
I'm curious as to why 'git rebase -m' isn't the default and what the
real difference is between 'git rebase' and 'git rebase -m'.
Additionally, is there any documentation describing how the patch
algorithm determines context?
Thanks!
Josh
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html