Hi, meanlo...@gmail.com wrote:
> 2. commit test.txt to master: > line1 > line1 > > 3. branch and checkout branch1 > 4. make and commit the following change to branch1: > #line1 > #line2 > > 5. checkout master > 6. make and commit the following change to master: > line1 > #line2 > > 7. merge branch1, git sees a conflict: > <<<<<<< HEAD > line1 > ======= > #line1 > >>>>>>> branch1 > #line2 > > Why? Thanks for a clear example. On branch1 you made the following change: (a) modify lines 1 and 2 On master, you made a different change: (b) just modify line 2 The changes touch the same chunk of lines and don't produce the same result there. Git is being conservative and letting you know that the two branches didn't agree about what line 1 should say. On the other hand, if you had a larger files and on branch1 made the following change: (a) modify lines 1 and 101 and on master, you made a different change: (b) just modify line 101 then the changes are touching different parts of the code and are merged independently. The result would be a clean merge where lines 1 and 101 are both modified. Git's conservatism can be helpful when working with code, where adjacent lines are likely to be affecting a single behavior and the conflict can help the operator to know to be extra careful. It makes less sense for line-oriented input where every line is independent. If you are often making changes to a line-oriented file, it may make sense to set up a custom merge driver to override git's merge behavior for that file. See 'Defining a custom merge driver' in gitattributes(5) for details about how that works. Hope that helps, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
