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
