Re: [PATCH 2/4] merge-recursive: increase marker length with depth of recursion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Elijah Newren <newren@xxxxxxxxx> writes:

> When using merge.conflictstyle=diff3 to have the "base version" be shown
> in conflicts, there is the possibility that the base version itself has
> conflicts in it.  This comes about when there are more than one merge
> base, and the merging of those merge bases produces a conflict.
> Since this process applies recursively, it is possible to have conflict
> markers nested at an arbitrary depth; to be able to differentiate the
> conflict markers from different nestings, we make them all of different
> lengths.

I know it is possible that the common ancestor part that is enclosed
by the outermost makers can have arbitrary conflicts, and they can
be even recursive conflicts.  But I fail to see why it is a problem.
Perhaps that is because I am not particularly good at resolving
merge conflicts, but as long as the common part of the outermost
merge is identifyable, would that really matter?  What I would do
while looking at common ancestor part with conflicts (not even a
recursive one) is just to ignore it, so...

Not that I strongly oppose to incrementing the marker length at
every level.  I do not think it would hurt, but I just do not see
how it would help.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux