xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
/*
|
|
|
|
* LibXDiff by Davide Libenzi ( File Differential Library )
|
|
|
|
* Copyright (C) 2003-2006 Davide Libenzi, Johannes E. Schindelin
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2017-11-07 06:39:33 +01:00
|
|
|
* License along with this library; if not, see
|
|
|
|
* <http://www.gnu.org/licenses/>.
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
*
|
|
|
|
* Davide Libenzi <davidel@xmailserver.org>
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "xinclude.h"
|
|
|
|
|
|
|
|
typedef struct s_xdmerge {
|
|
|
|
struct s_xdmerge *next;
|
|
|
|
/*
|
|
|
|
* 0 = conflict,
|
|
|
|
* 1 = no conflict, take first,
|
|
|
|
* 2 = no conflict, take second.
|
2010-03-01 22:46:25 +01:00
|
|
|
* 3 = no conflict, take both.
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
*/
|
|
|
|
int mode;
|
2008-08-28 10:10:04 +02:00
|
|
|
/*
|
|
|
|
* These point at the respective postimages. E.g. <i1,chg1> is
|
|
|
|
* how side #1 wants to change the common ancestor; if there is no
|
|
|
|
* overlap, lines before i1 in the postimage of side #1 appear
|
|
|
|
* in the merge result as a region touched by neither side.
|
|
|
|
*/
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
long i1, i2;
|
|
|
|
long chg1, chg2;
|
2008-08-28 10:10:04 +02:00
|
|
|
/*
|
|
|
|
* These point at the preimage; of course there is just one
|
|
|
|
* preimage, that is from the shared common ancestor.
|
|
|
|
*/
|
|
|
|
long i0;
|
|
|
|
long chg0;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
} xdmerge_t;
|
|
|
|
|
|
|
|
static int xdl_append_merge(xdmerge_t **merge, int mode,
|
2008-08-28 10:10:04 +02:00
|
|
|
long i0, long chg0,
|
|
|
|
long i1, long chg1,
|
|
|
|
long i2, long chg2)
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
{
|
|
|
|
xdmerge_t *m = *merge;
|
2006-12-05 22:15:35 +01:00
|
|
|
if (m && (i1 <= m->i1 + m->chg1 || i2 <= m->i2 + m->chg2)) {
|
|
|
|
if (mode != m->mode)
|
|
|
|
m->mode = 0;
|
2008-08-28 10:10:04 +02:00
|
|
|
m->chg0 = i0 + chg0 - m->i0;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
m->chg1 = i1 + chg1 - m->i1;
|
|
|
|
m->chg2 = i2 + chg2 - m->i2;
|
|
|
|
} else {
|
|
|
|
m = xdl_malloc(sizeof(xdmerge_t));
|
|
|
|
if (!m)
|
|
|
|
return -1;
|
|
|
|
m->next = NULL;
|
|
|
|
m->mode = mode;
|
2008-08-28 10:10:04 +02:00
|
|
|
m->i0 = i0;
|
|
|
|
m->chg0 = chg0;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
m->i1 = i1;
|
|
|
|
m->chg1 = chg1;
|
|
|
|
m->i2 = i2;
|
|
|
|
m->chg2 = chg2;
|
|
|
|
if (*merge)
|
|
|
|
(*merge)->next = m;
|
|
|
|
*merge = m;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int xdl_cleanup_merge(xdmerge_t *c)
|
|
|
|
{
|
|
|
|
int count = 0;
|
|
|
|
xdmerge_t *next_c;
|
|
|
|
|
|
|
|
/* were there conflicts? */
|
|
|
|
for (; c; c = next_c) {
|
|
|
|
if (c->mode == 0)
|
|
|
|
count++;
|
|
|
|
next_c = c->next;
|
|
|
|
free(c);
|
|
|
|
}
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int xdl_merge_cmp_lines(xdfenv_t *xe1, int i1, xdfenv_t *xe2, int i2,
|
|
|
|
int line_count, long flags)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
xrecord_t **rec1 = xe1->xdf2.recs + i1;
|
|
|
|
xrecord_t **rec2 = xe2->xdf2.recs + i2;
|
|
|
|
|
|
|
|
for (i = 0; i < line_count; i++) {
|
|
|
|
int result = xdl_recmatch(rec1[i]->ptr, rec1[i]->size,
|
|
|
|
rec2[i]->ptr, rec2[i]->size, flags);
|
|
|
|
if (!result)
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-01-27 17:37:40 +01:00
|
|
|
static int xdl_recs_copy_0(int use_orig, xdfenv_t *xe, int i, int count, int needs_cr, int add_nl, char *dest)
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
{
|
2008-08-28 10:10:04 +02:00
|
|
|
xrecord_t **recs;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
int size = 0;
|
|
|
|
|
2008-08-28 10:10:04 +02:00
|
|
|
recs = (use_orig ? xe->xdf1.recs : xe->xdf2.recs) + i;
|
|
|
|
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
if (count < 1)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
for (i = 0; i < count; size += recs[i++]->size)
|
|
|
|
if (dest)
|
|
|
|
memcpy(dest + size, recs[i]->ptr, recs[i]->size);
|
|
|
|
if (add_nl) {
|
|
|
|
i = recs[count - 1]->size;
|
|
|
|
if (i == 0 || recs[count - 1]->ptr[i - 1] != '\n') {
|
2016-01-27 17:37:40 +01:00
|
|
|
if (needs_cr) {
|
|
|
|
if (dest)
|
|
|
|
dest[size] = '\r';
|
|
|
|
size++;
|
|
|
|
}
|
|
|
|
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
if (dest)
|
|
|
|
dest[size] = '\n';
|
|
|
|
size++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
2016-01-27 17:37:40 +01:00
|
|
|
static int xdl_recs_copy(xdfenv_t *xe, int i, int count, int needs_cr, int add_nl, char *dest)
|
2008-08-28 10:10:04 +02:00
|
|
|
{
|
2016-01-27 17:37:40 +01:00
|
|
|
return xdl_recs_copy_0(0, xe, i, count, needs_cr, add_nl, dest);
|
2008-08-28 10:10:04 +02:00
|
|
|
}
|
|
|
|
|
2016-01-27 17:37:40 +01:00
|
|
|
static int xdl_orig_copy(xdfenv_t *xe, int i, int count, int needs_cr, int add_nl, char *dest)
|
2008-08-28 10:10:04 +02:00
|
|
|
{
|
2016-01-27 17:37:40 +01:00
|
|
|
return xdl_recs_copy_0(1, xe, i, count, needs_cr, add_nl, dest);
|
2008-08-28 10:10:04 +02:00
|
|
|
}
|
|
|
|
|
merge-file: let conflict markers match end-of-line style of the context
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.
This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.
The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!
Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-27 17:37:36 +01:00
|
|
|
/*
|
|
|
|
* Returns 1 if the i'th line ends in CR/LF (if it is the last line and
|
|
|
|
* has no eol, the preceding line, if any), 0 if it ends in LF-only, and
|
|
|
|
* -1 if the line ending cannot be determined.
|
|
|
|
*/
|
|
|
|
static int is_eol_crlf(xdfile_t *file, int i)
|
|
|
|
{
|
|
|
|
long size;
|
|
|
|
|
|
|
|
if (i < file->nrec - 1)
|
|
|
|
/* All lines before the last *must* end in LF */
|
|
|
|
return (size = file->recs[i]->size) > 1 &&
|
|
|
|
file->recs[i]->ptr[size - 2] == '\r';
|
|
|
|
if (!file->nrec)
|
|
|
|
/* Cannot determine eol style from empty file */
|
|
|
|
return -1;
|
|
|
|
if ((size = file->recs[i]->size) &&
|
|
|
|
file->recs[i]->ptr[size - 1] == '\n')
|
|
|
|
/* Last line; ends in LF; Is it CR/LF? */
|
|
|
|
return size > 1 &&
|
|
|
|
file->recs[i]->ptr[size - 2] == '\r';
|
|
|
|
if (!i)
|
|
|
|
/* The only line has no eol */
|
|
|
|
return -1;
|
|
|
|
/* Determine eol from second-to-last line */
|
|
|
|
return (size = file->recs[i - 1]->size) > 1 &&
|
|
|
|
file->recs[i - 1]->ptr[size - 2] == '\r';
|
|
|
|
}
|
|
|
|
|
|
|
|
static int is_cr_needed(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m)
|
|
|
|
{
|
|
|
|
int needs_cr;
|
|
|
|
|
|
|
|
/* Match post-images' preceding, or first, lines' end-of-line style */
|
|
|
|
needs_cr = is_eol_crlf(&xe1->xdf2, m->i1 ? m->i1 - 1 : 0);
|
|
|
|
if (needs_cr)
|
|
|
|
needs_cr = is_eol_crlf(&xe2->xdf2, m->i2 ? m->i2 - 1 : 0);
|
|
|
|
/* Look at pre-image's first line, unless we already settled on LF */
|
|
|
|
if (needs_cr)
|
|
|
|
needs_cr = is_eol_crlf(&xe1->xdf1, 0);
|
|
|
|
/* If still undecided, use LF-only */
|
|
|
|
return needs_cr < 0 ? 0 : needs_cr;
|
|
|
|
}
|
|
|
|
|
2008-08-28 10:04:00 +02:00
|
|
|
static int fill_conflict_hunk(xdfenv_t *xe1, const char *name1,
|
|
|
|
xdfenv_t *xe2, const char *name2,
|
2010-03-21 01:31:44 +01:00
|
|
|
const char *name3,
|
2008-08-28 10:10:04 +02:00
|
|
|
int size, int i, int style,
|
2010-01-17 06:30:18 +01:00
|
|
|
xdmerge_t *m, char *dest, int marker_size)
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
{
|
|
|
|
int marker1_size = (name1 ? strlen(name1) + 1 : 0);
|
|
|
|
int marker2_size = (name2 ? strlen(name2) + 1 : 0);
|
2010-03-21 01:31:44 +01:00
|
|
|
int marker3_size = (name3 ? strlen(name3) + 1 : 0);
|
merge-file: let conflict markers match end-of-line style of the context
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.
This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.
The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!
Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-27 17:37:36 +01:00
|
|
|
int needs_cr = is_cr_needed(xe1, xe2, m);
|
2008-08-28 10:04:00 +02:00
|
|
|
|
2010-01-17 06:30:18 +01:00
|
|
|
if (marker_size <= 0)
|
|
|
|
marker_size = DEFAULT_CONFLICT_MARKER_SIZE;
|
|
|
|
|
2008-08-28 10:04:00 +02:00
|
|
|
/* Before conflicting part */
|
2016-01-27 17:37:40 +01:00
|
|
|
size += xdl_recs_copy(xe1, i, m->i1 - i, 0, 0,
|
2008-08-28 10:04:00 +02:00
|
|
|
dest ? dest + size : NULL);
|
|
|
|
|
|
|
|
if (!dest) {
|
merge-file: let conflict markers match end-of-line style of the context
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.
This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.
The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!
Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-27 17:37:36 +01:00
|
|
|
size += marker_size + 1 + needs_cr + marker1_size;
|
2008-08-28 10:04:00 +02:00
|
|
|
} else {
|
2010-04-28 13:29:06 +02:00
|
|
|
memset(dest + size, '<', marker_size);
|
|
|
|
size += marker_size;
|
2008-08-28 10:04:00 +02:00
|
|
|
if (marker1_size) {
|
|
|
|
dest[size] = ' ';
|
|
|
|
memcpy(dest + size + 1, name1, marker1_size - 1);
|
|
|
|
size += marker1_size;
|
|
|
|
}
|
merge-file: let conflict markers match end-of-line style of the context
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.
This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.
The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!
Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-27 17:37:36 +01:00
|
|
|
if (needs_cr)
|
|
|
|
dest[size++] = '\r';
|
2008-08-28 10:04:00 +02:00
|
|
|
dest[size++] = '\n';
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Postimage from side #1 */
|
2016-01-27 17:37:40 +01:00
|
|
|
size += xdl_recs_copy(xe1, m->i1, m->chg1, needs_cr, 1,
|
2008-08-28 10:04:00 +02:00
|
|
|
dest ? dest + size : NULL);
|
2008-08-28 10:10:04 +02:00
|
|
|
|
xdiff: implement a zealous diff3, or "zdiff3"
"zdiff3" is identical to ordinary diff3 except that it allows compaction
of common lines on the two sides of history at the beginning or end of
the conflict hunk. For example, the following diff3 conflict:
1
2
3
4
<<<<<<
A
B
C
D
E
||||||
5
6
======
A
X
C
Y
E
>>>>>>
7
8
9
has common lines 'A', 'C', and 'E' on the two sides. With zdiff3, one
would instead get the following conflict:
1
2
3
4
A
<<<<<<
B
C
D
||||||
5
6
======
X
C
Y
>>>>>>
E
7
8
9
Note that the common lines, 'A', and 'E' were moved outside the
conflict. Unlike with the two-way conflicts from the 'merge'
conflictStyle, the zdiff3 conflict is NOT split into multiple conflict
regions to allow the common 'C' lines to be shown outside a conflict,
because zdiff3 shows the base version too and the base version cannot be
reasonably split.
Note also that the removing of lines common to the two sides might make
the remaining text inside the conflict region match the base text inside
the conflict region (for example, if the diff3 conflict had '5 6 E' on
the right side of the conflict, then the common line 'E' would be moved
outside and both the base and right side's remaining conflict text would
be the lines '5' and '6'). This has the potential to surprise users and
make them think there should not have been a conflict, but there
definitely was a conflict and it should remain.
Based-on-patch-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Co-authored-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-01 01:05:06 +01:00
|
|
|
if (style == XDL_MERGE_DIFF3 || style == XDL_MERGE_ZEALOUS_DIFF3) {
|
2008-08-28 10:10:04 +02:00
|
|
|
/* Shared preimage */
|
|
|
|
if (!dest) {
|
merge-file: let conflict markers match end-of-line style of the context
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.
This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.
The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!
Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-27 17:37:36 +01:00
|
|
|
size += marker_size + 1 + needs_cr + marker3_size;
|
2008-08-28 10:10:04 +02:00
|
|
|
} else {
|
2010-04-28 13:29:06 +02:00
|
|
|
memset(dest + size, '|', marker_size);
|
|
|
|
size += marker_size;
|
2010-03-21 01:31:44 +01:00
|
|
|
if (marker3_size) {
|
|
|
|
dest[size] = ' ';
|
|
|
|
memcpy(dest + size + 1, name3, marker3_size - 1);
|
|
|
|
size += marker3_size;
|
|
|
|
}
|
merge-file: let conflict markers match end-of-line style of the context
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.
This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.
The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!
Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-27 17:37:36 +01:00
|
|
|
if (needs_cr)
|
|
|
|
dest[size++] = '\r';
|
2008-08-28 10:10:04 +02:00
|
|
|
dest[size++] = '\n';
|
|
|
|
}
|
2016-01-27 17:37:40 +01:00
|
|
|
size += xdl_orig_copy(xe1, m->i0, m->chg0, needs_cr, 1,
|
2008-08-28 10:10:04 +02:00
|
|
|
dest ? dest + size : NULL);
|
|
|
|
}
|
|
|
|
|
2008-08-28 10:04:00 +02:00
|
|
|
if (!dest) {
|
merge-file: let conflict markers match end-of-line style of the context
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.
This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.
The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!
Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-27 17:37:36 +01:00
|
|
|
size += marker_size + 1 + needs_cr;
|
2008-08-28 10:04:00 +02:00
|
|
|
} else {
|
2010-04-28 13:29:06 +02:00
|
|
|
memset(dest + size, '=', marker_size);
|
|
|
|
size += marker_size;
|
merge-file: let conflict markers match end-of-line style of the context
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.
This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.
The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!
Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-27 17:37:36 +01:00
|
|
|
if (needs_cr)
|
|
|
|
dest[size++] = '\r';
|
2008-08-28 10:04:00 +02:00
|
|
|
dest[size++] = '\n';
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Postimage from side #2 */
|
2016-01-27 17:37:40 +01:00
|
|
|
size += xdl_recs_copy(xe2, m->i2, m->chg2, needs_cr, 1,
|
2008-08-28 10:04:00 +02:00
|
|
|
dest ? dest + size : NULL);
|
|
|
|
if (!dest) {
|
merge-file: let conflict markers match end-of-line style of the context
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.
This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.
The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!
Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-27 17:37:36 +01:00
|
|
|
size += marker_size + 1 + needs_cr + marker2_size;
|
2008-08-28 10:04:00 +02:00
|
|
|
} else {
|
2010-04-28 13:29:06 +02:00
|
|
|
memset(dest + size, '>', marker_size);
|
|
|
|
size += marker_size;
|
2008-08-28 10:04:00 +02:00
|
|
|
if (marker2_size) {
|
|
|
|
dest[size] = ' ';
|
|
|
|
memcpy(dest + size + 1, name2, marker2_size - 1);
|
|
|
|
size += marker2_size;
|
|
|
|
}
|
merge-file: let conflict markers match end-of-line style of the context
When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.
This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.
The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!
Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.
We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.
So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.
Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-27 17:37:36 +01:00
|
|
|
if (needs_cr)
|
|
|
|
dest[size++] = '\r';
|
2008-08-28 10:04:00 +02:00
|
|
|
dest[size++] = '\n';
|
|
|
|
}
|
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int xdl_fill_merge_buffer(xdfenv_t *xe1, const char *name1,
|
2008-08-28 10:10:04 +02:00
|
|
|
xdfenv_t *xe2, const char *name2,
|
2010-03-21 01:31:44 +01:00
|
|
|
const char *ancestor_name,
|
2008-06-20 09:17:27 +02:00
|
|
|
int favor,
|
2010-01-17 06:30:18 +01:00
|
|
|
xdmerge_t *m, char *dest, int style,
|
|
|
|
int marker_size)
|
2008-08-28 10:04:00 +02:00
|
|
|
{
|
|
|
|
int size, i;
|
|
|
|
|
|
|
|
for (size = i = 0; m; m = m->next) {
|
2008-06-20 09:17:27 +02:00
|
|
|
if (favor && !m->mode)
|
|
|
|
m->mode = favor;
|
|
|
|
|
2008-08-28 10:04:00 +02:00
|
|
|
if (m->mode == 0)
|
|
|
|
size = fill_conflict_hunk(xe1, name1, xe2, name2,
|
2010-03-21 01:31:44 +01:00
|
|
|
ancestor_name,
|
2010-01-17 06:30:18 +01:00
|
|
|
size, i, style, m, dest,
|
|
|
|
marker_size);
|
2010-03-01 22:46:25 +01:00
|
|
|
else if (m->mode & 3) {
|
|
|
|
/* Before conflicting part */
|
2016-01-27 17:37:40 +01:00
|
|
|
size += xdl_recs_copy(xe1, i, m->i1 - i, 0, 0,
|
2008-08-28 10:04:00 +02:00
|
|
|
dest ? dest + size : NULL);
|
2010-03-01 22:46:25 +01:00
|
|
|
/* Postimage from side #1 */
|
2016-01-27 17:37:40 +01:00
|
|
|
if (m->mode & 1) {
|
|
|
|
int needs_cr = is_cr_needed(xe1, xe2, m);
|
|
|
|
|
|
|
|
size += xdl_recs_copy(xe1, m->i1, m->chg1, needs_cr, (m->mode & 2),
|
2010-03-01 22:46:25 +01:00
|
|
|
dest ? dest + size : NULL);
|
2016-01-27 17:37:40 +01:00
|
|
|
}
|
2010-03-01 22:46:25 +01:00
|
|
|
/* Postimage from side #2 */
|
|
|
|
if (m->mode & 2)
|
2016-01-27 17:37:40 +01:00
|
|
|
size += xdl_recs_copy(xe2, m->i2, m->chg2, 0, 0,
|
2010-03-01 22:46:25 +01:00
|
|
|
dest ? dest + size : NULL);
|
|
|
|
} else
|
2006-12-31 02:07:41 +01:00
|
|
|
continue;
|
2008-08-28 10:04:00 +02:00
|
|
|
i = m->i1 + m->chg1;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
}
|
2016-01-27 17:37:40 +01:00
|
|
|
size += xdl_recs_copy(xe1, i, xe1->xdf2.nrec - i, 0, 0,
|
2008-08-28 10:04:00 +02:00
|
|
|
dest ? dest + size : NULL);
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
xdiff: implement a zealous diff3, or "zdiff3"
"zdiff3" is identical to ordinary diff3 except that it allows compaction
of common lines on the two sides of history at the beginning or end of
the conflict hunk. For example, the following diff3 conflict:
1
2
3
4
<<<<<<
A
B
C
D
E
||||||
5
6
======
A
X
C
Y
E
>>>>>>
7
8
9
has common lines 'A', 'C', and 'E' on the two sides. With zdiff3, one
would instead get the following conflict:
1
2
3
4
A
<<<<<<
B
C
D
||||||
5
6
======
X
C
Y
>>>>>>
E
7
8
9
Note that the common lines, 'A', and 'E' were moved outside the
conflict. Unlike with the two-way conflicts from the 'merge'
conflictStyle, the zdiff3 conflict is NOT split into multiple conflict
regions to allow the common 'C' lines to be shown outside a conflict,
because zdiff3 shows the base version too and the base version cannot be
reasonably split.
Note also that the removing of lines common to the two sides might make
the remaining text inside the conflict region match the base text inside
the conflict region (for example, if the diff3 conflict had '5 6 E' on
the right side of the conflict, then the common line 'E' would be moved
outside and both the base and right side's remaining conflict text would
be the lines '5' and '6'). This has the potential to surprise users and
make them think there should not have been a conflict, but there
definitely was a conflict and it should remain.
Based-on-patch-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Co-authored-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-01 01:05:06 +01:00
|
|
|
static int recmatch(xrecord_t *rec1, xrecord_t *rec2, unsigned long flags)
|
|
|
|
{
|
|
|
|
return xdl_recmatch(rec1->ptr, rec1->size,
|
|
|
|
rec2->ptr, rec2->size, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove any common lines from the beginning and end of the conflicted region.
|
|
|
|
*/
|
|
|
|
static void xdl_refine_zdiff3_conflicts(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m,
|
|
|
|
xpparam_t const *xpp)
|
|
|
|
{
|
|
|
|
xrecord_t **rec1 = xe1->xdf2.recs, **rec2 = xe2->xdf2.recs;
|
|
|
|
for (; m; m = m->next) {
|
|
|
|
/* let's handle just the conflicts */
|
|
|
|
if (m->mode)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
while(m->chg1 && m->chg2 &&
|
|
|
|
recmatch(rec1[m->i1], rec2[m->i2], xpp->flags)) {
|
|
|
|
m->chg1--;
|
|
|
|
m->chg2--;
|
|
|
|
m->i1++;
|
|
|
|
m->i2++;
|
|
|
|
}
|
|
|
|
while (m->chg1 && m->chg2 &&
|
|
|
|
recmatch(rec1[m->i1 + m->chg1 - 1],
|
|
|
|
rec2[m->i2 + m->chg2 - 1], xpp->flags)) {
|
|
|
|
m->chg1--;
|
|
|
|
m->chg2--;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
/*
|
|
|
|
* Sometimes, changes are not quite identical, but differ in only a few
|
|
|
|
* lines. Try hard to show only these few lines as conflicting.
|
|
|
|
*/
|
|
|
|
static int xdl_refine_conflicts(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m,
|
|
|
|
xpparam_t const *xpp)
|
|
|
|
{
|
|
|
|
for (; m; m = m->next) {
|
|
|
|
mmfile_t t1, t2;
|
|
|
|
xdfenv_t xe;
|
|
|
|
xdchange_t *xscr, *x;
|
|
|
|
int i1 = m->i1, i2 = m->i2;
|
|
|
|
|
|
|
|
/* let's handle just the conflicts */
|
|
|
|
if (m->mode)
|
|
|
|
continue;
|
|
|
|
|
2006-12-28 17:13:33 +01:00
|
|
|
/* no sense refining a conflict when one side is empty */
|
|
|
|
if (m->chg1 == 0 || m->chg2 == 0)
|
|
|
|
continue;
|
|
|
|
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
/*
|
|
|
|
* This probably does not work outside git, since
|
|
|
|
* we have a very simple mmfile structure.
|
|
|
|
*/
|
|
|
|
t1.ptr = (char *)xe1->xdf2.recs[m->i1]->ptr;
|
2006-11-30 00:24:32 +01:00
|
|
|
t1.size = xe1->xdf2.recs[m->i1 + m->chg1 - 1]->ptr
|
|
|
|
+ xe1->xdf2.recs[m->i1 + m->chg1 - 1]->size - t1.ptr;
|
|
|
|
t2.ptr = (char *)xe2->xdf2.recs[m->i2]->ptr;
|
|
|
|
t2.size = xe2->xdf2.recs[m->i2 + m->chg2 - 1]->ptr
|
|
|
|
+ xe2->xdf2.recs[m->i2 + m->chg2 - 1]->size - t2.ptr;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
if (xdl_do_diff(&t1, &t2, xpp, &xe) < 0)
|
|
|
|
return -1;
|
|
|
|
if (xdl_change_compact(&xe.xdf1, &xe.xdf2, xpp->flags) < 0 ||
|
|
|
|
xdl_change_compact(&xe.xdf2, &xe.xdf1, xpp->flags) < 0 ||
|
|
|
|
xdl_build_script(&xe, &xscr) < 0) {
|
|
|
|
xdl_free_env(&xe);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (!xscr) {
|
2006-12-31 02:07:41 +01:00
|
|
|
/* If this happens, the changes are identical. */
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
xdl_free_env(&xe);
|
2006-12-31 02:07:41 +01:00
|
|
|
m->mode = 4;
|
|
|
|
continue;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
}
|
|
|
|
x = xscr;
|
|
|
|
m->i1 = xscr->i1 + i1;
|
|
|
|
m->chg1 = xscr->chg1;
|
|
|
|
m->i2 = xscr->i2 + i2;
|
|
|
|
m->chg2 = xscr->chg2;
|
|
|
|
while (xscr->next) {
|
|
|
|
xdmerge_t *m2 = xdl_malloc(sizeof(xdmerge_t));
|
|
|
|
if (!m2) {
|
|
|
|
xdl_free_env(&xe);
|
|
|
|
xdl_free_script(x);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
xscr = xscr->next;
|
|
|
|
m2->next = m->next;
|
|
|
|
m->next = m2;
|
|
|
|
m = m2;
|
|
|
|
m->mode = 0;
|
|
|
|
m->i1 = xscr->i1 + i1;
|
|
|
|
m->chg1 = xscr->chg1;
|
|
|
|
m->i2 = xscr->i2 + i2;
|
|
|
|
m->chg2 = xscr->chg2;
|
|
|
|
}
|
|
|
|
xdl_free_env(&xe);
|
|
|
|
xdl_free_script(x);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-02-17 20:07:40 +01:00
|
|
|
static int line_contains_alnum(const char *ptr, long size)
|
|
|
|
{
|
|
|
|
while (size--)
|
2010-10-04 11:09:17 +02:00
|
|
|
if (isalnum((unsigned char)*(ptr++)))
|
2008-02-17 20:07:40 +01:00
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int lines_contain_alnum(xdfenv_t *xe, int i, int chg)
|
|
|
|
{
|
|
|
|
for (; chg; chg--, i++)
|
|
|
|
if (line_contains_alnum(xe->xdf2.recs[i]->ptr,
|
|
|
|
xe->xdf2.recs[i]->size))
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-02-17 20:07:19 +01:00
|
|
|
/*
|
|
|
|
* This function merges m and m->next, marking everything between those hunks
|
|
|
|
* as conflicting, too.
|
|
|
|
*/
|
|
|
|
static void xdl_merge_two_conflicts(xdmerge_t *m)
|
|
|
|
{
|
|
|
|
xdmerge_t *next_m = m->next;
|
|
|
|
m->chg1 = next_m->i1 + next_m->chg1 - m->i1;
|
|
|
|
m->chg2 = next_m->i2 + next_m->chg2 - m->i2;
|
|
|
|
m->next = next_m->next;
|
|
|
|
free(next_m);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there are less than 3 non-conflicting lines between conflicts,
|
|
|
|
* it appears simpler -- because it takes up less (or as many) lines --
|
|
|
|
* if the lines are moved into the conflicts.
|
|
|
|
*/
|
2008-02-17 20:07:40 +01:00
|
|
|
static int xdl_simplify_non_conflicts(xdfenv_t *xe1, xdmerge_t *m,
|
|
|
|
int simplify_if_no_alnum)
|
2008-02-17 20:07:19 +01:00
|
|
|
{
|
|
|
|
int result = 0;
|
|
|
|
|
|
|
|
if (!m)
|
|
|
|
return result;
|
|
|
|
for (;;) {
|
|
|
|
xdmerge_t *next_m = m->next;
|
|
|
|
int begin, end;
|
|
|
|
|
|
|
|
if (!next_m)
|
|
|
|
return result;
|
|
|
|
|
|
|
|
begin = m->i1 + m->chg1;
|
|
|
|
end = next_m->i1;
|
|
|
|
|
2008-02-17 20:07:40 +01:00
|
|
|
if (m->mode != 0 || next_m->mode != 0 ||
|
|
|
|
(end - begin > 3 &&
|
|
|
|
(!simplify_if_no_alnum ||
|
|
|
|
lines_contain_alnum(xe1, begin, end - begin)))) {
|
2008-02-17 20:07:19 +01:00
|
|
|
m = next_m;
|
2008-02-17 20:07:40 +01:00
|
|
|
} else {
|
2008-02-17 20:07:19 +01:00
|
|
|
result++;
|
|
|
|
xdl_merge_two_conflicts(m);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
/*
|
|
|
|
* level == 0: mark all overlapping changes as conflict
|
|
|
|
* level == 1: mark overlapping changes as conflict only if not identical
|
|
|
|
* level == 2: analyze non-identical changes for minimal conflict set
|
2008-02-17 20:07:40 +01:00
|
|
|
* level == 3: analyze non-identical changes for minimal conflict set, but
|
|
|
|
* treat hunks not containing any letter or number as conflicting
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
*
|
|
|
|
* returns < 0 on error, == 0 for no conflicts, else number of conflicts
|
|
|
|
*/
|
2010-03-21 01:35:18 +01:00
|
|
|
static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1,
|
|
|
|
xdfenv_t *xe2, xdchange_t *xscr2,
|
|
|
|
xmparam_t const *xmp, mmbuffer_t *result)
|
|
|
|
{
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
xdmerge_t *changes, *c;
|
2010-01-17 06:30:18 +01:00
|
|
|
xpparam_t const *xpp = &xmp->xpp;
|
2010-03-21 01:31:44 +01:00
|
|
|
const char *const ancestor_name = xmp->ancestor;
|
2010-03-21 01:35:18 +01:00
|
|
|
const char *const name1 = xmp->file1;
|
|
|
|
const char *const name2 = xmp->file2;
|
2008-08-28 10:10:04 +02:00
|
|
|
int i0, i1, i2, chg0, chg1, chg2;
|
2010-03-01 22:46:26 +01:00
|
|
|
int level = xmp->level;
|
|
|
|
int style = xmp->style;
|
|
|
|
int favor = xmp->favor;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
|
xdiff: implement a zealous diff3, or "zdiff3"
"zdiff3" is identical to ordinary diff3 except that it allows compaction
of common lines on the two sides of history at the beginning or end of
the conflict hunk. For example, the following diff3 conflict:
1
2
3
4
<<<<<<
A
B
C
D
E
||||||
5
6
======
A
X
C
Y
E
>>>>>>
7
8
9
has common lines 'A', 'C', and 'E' on the two sides. With zdiff3, one
would instead get the following conflict:
1
2
3
4
A
<<<<<<
B
C
D
||||||
5
6
======
X
C
Y
>>>>>>
E
7
8
9
Note that the common lines, 'A', and 'E' were moved outside the
conflict. Unlike with the two-way conflicts from the 'merge'
conflictStyle, the zdiff3 conflict is NOT split into multiple conflict
regions to allow the common 'C' lines to be shown outside a conflict,
because zdiff3 shows the base version too and the base version cannot be
reasonably split.
Note also that the removing of lines common to the two sides might make
the remaining text inside the conflict region match the base text inside
the conflict region (for example, if the diff3 conflict had '5 6 E' on
the right side of the conflict, then the common line 'E' would be moved
outside and both the base and right side's remaining conflict text would
be the lines '5' and '6'). This has the potential to surprise users and
make them think there should not have been a conflict, but there
definitely was a conflict and it should remain.
Based-on-patch-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Co-authored-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-01 01:05:06 +01:00
|
|
|
/*
|
|
|
|
* XDL_MERGE_DIFF3 does not attempt to refine conflicts by looking
|
|
|
|
* at common areas of sides 1 & 2, because the base (side 0) does
|
|
|
|
* not match and is being shown. Similarly, simplification of
|
|
|
|
* non-conflicts is also skipped due to the skipping of conflict
|
|
|
|
* refinement.
|
|
|
|
*
|
|
|
|
* XDL_MERGE_ZEALOUS_DIFF3, on the other hand, will attempt to
|
|
|
|
* refine conflicts looking for common areas of sides 1 & 2.
|
|
|
|
* However, since the base is being shown and does not match,
|
|
|
|
* it will only look for common areas at the beginning or end
|
|
|
|
* of the conflict block. Since XDL_MERGE_ZEALOUS_DIFF3's
|
|
|
|
* conflict refinement is much more limited in this fashion, the
|
|
|
|
* conflict simplification will be skipped.
|
|
|
|
*/
|
|
|
|
if (style == XDL_MERGE_DIFF3 || style == XDL_MERGE_ZEALOUS_DIFF3) {
|
xmerge.c: "diff3 -m" style clips merge reduction level to EAGER or less
When showing a conflicting merge result, and "--diff3 -m" style is asked
for, this patch makes sure that the merge reduction level does not exceed
XDL_MERGE_EAGER. This is because "diff3 -m" style output would not make
sense for anything more aggressive than XDL_MERGE_EAGER, because of the
way how the merge reduction works.
"git merge-file" no longer has to force MERGE_EAGER when "--diff3" is
asked for because of this change.
Suppose a common ancestor (shared preimage) is modified to postimage #1
and #2 (each letter represents one line):
#####
postimage#1: 1234ABCDE789
| /
| /
preimage: 123456789
| \
postimage#2: 1234AXYE789
####
XDL_MERGE_MINIMAL and XDL_MERGE_EAGER would:
(1) find the s/56/ABCDE/ done on one side and s/56/AXYE/ done on the
other side,
(2) notice that they touch an overlapping area, and
(3) mark it as a conflict, "ABCDE vs AXYE".
The difference between the two algorithms is that EAGER drops the hunk
altogether if the postimages match (i.e. both sides modified the same
way), while MINIMAL keeps it. There is no other operation performed to
the hunk. As the result, lines marked with "#" in the above picure will
be in the RCS merge style output like this (letters <, = and > represent
conflict marker lines):
output: 1234<ABCDE=AXYE>789 ; with MINIMAL/EAGER
The part from the preimage that corresponds to these conflicting changes
is "56", which is what "diff3 -m" style output adds to it:
output: 1234<ABCDE|56=AXYE>789 ; in "diff3 -m" style
Now, XDL_MERGE_ZEALOUS looks at the differences between the changes two
postimages made in order to reduce the number of lines in the conflicting
regions. It notices that both sides start their new contents with "A",
and excludes it from the output (it also excludes "E" for the same
reason). The conflict that used to be "ABCDE vs AXYE" is now "BCD vs XY":
output: 1234A<BCD=XY>E789 ; with ZEALOUS
There could even be matching parts between two postimages in the middle.
Instead of one side rewriting the shared "56" to "ABCDE" and the other
side to "AXYE", imagine the case where the postimages are "ABCDE" and
"AXCYE", in which case instead of having one conflicted hunk "BCD vs XY",
you would have two conflicting hunks "B vs X" and "D vs Y".
In either case, once you reduce "ABCDE vs AXYE" to "BCD vs XY" (or "ABCDE
vs AXCYE" to "B vs X" and "D vs Y"), there is no part from the preimage
that corresponds to the conflicting change made in both postimages
anymore. In other words, conflict reduced by ZEALOUS algorithm cannot be
expressed in "diff3 -m" style. Representing the last illustration like
this is misleading to say the least:
output: 1234A<BCD|56=XY>E789 ; broken "diff3 -m" style
because the preimage was not ...4A56E... to begin with. "A" and "E" are
common only between the postimages.
Even worse, once a single conflicting hunk is split into multiple ones
(recall the example of breaking "ABCDE vs AXCYE" to "B vs X" and "D vs
Y"), there is no sane way to distribute the preimage text across split
conflicting hunks.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-29 17:22:55 +02:00
|
|
|
/*
|
|
|
|
* "diff3 -m" output does not make sense for anything
|
|
|
|
* more aggressive than XDL_MERGE_EAGER.
|
|
|
|
*/
|
|
|
|
if (XDL_MERGE_EAGER < level)
|
|
|
|
level = XDL_MERGE_EAGER;
|
|
|
|
}
|
|
|
|
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
c = changes = NULL;
|
|
|
|
|
|
|
|
while (xscr1 && xscr2) {
|
|
|
|
if (!changes)
|
|
|
|
changes = c;
|
|
|
|
if (xscr1->i1 + xscr1->chg1 < xscr2->i1) {
|
2008-08-28 10:10:04 +02:00
|
|
|
i0 = xscr1->i1;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
i1 = xscr1->i2;
|
|
|
|
i2 = xscr2->i2 - xscr2->i1 + xscr1->i1;
|
2008-08-28 10:10:04 +02:00
|
|
|
chg0 = xscr1->chg1;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
chg1 = xscr1->chg2;
|
|
|
|
chg2 = xscr1->chg1;
|
2008-08-28 10:10:04 +02:00
|
|
|
if (xdl_append_merge(&c, 1,
|
|
|
|
i0, chg0, i1, chg1, i2, chg2)) {
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
xdl_cleanup_merge(changes);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
xscr1 = xscr1->next;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (xscr2->i1 + xscr2->chg1 < xscr1->i1) {
|
2008-08-28 10:10:04 +02:00
|
|
|
i0 = xscr2->i1;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
i1 = xscr1->i2 - xscr1->i1 + xscr2->i1;
|
|
|
|
i2 = xscr2->i2;
|
2008-08-28 10:10:04 +02:00
|
|
|
chg0 = xscr2->chg1;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
chg1 = xscr2->chg1;
|
|
|
|
chg2 = xscr2->chg2;
|
2008-08-28 10:10:04 +02:00
|
|
|
if (xdl_append_merge(&c, 2,
|
|
|
|
i0, chg0, i1, chg1, i2, chg2)) {
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
xdl_cleanup_merge(changes);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
xscr2 = xscr2->next;
|
|
|
|
continue;
|
|
|
|
}
|
2008-08-29 17:16:30 +02:00
|
|
|
if (level == XDL_MERGE_MINIMAL || xscr1->i1 != xscr2->i1 ||
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
xscr1->chg1 != xscr2->chg1 ||
|
|
|
|
xscr1->chg2 != xscr2->chg2 ||
|
|
|
|
xdl_merge_cmp_lines(xe1, xscr1->i2,
|
|
|
|
xe2, xscr2->i2,
|
|
|
|
xscr1->chg2, xpp->flags)) {
|
|
|
|
/* conflict */
|
|
|
|
int off = xscr1->i1 - xscr2->i1;
|
|
|
|
int ffo = off + xscr1->chg1 - xscr2->chg1;
|
|
|
|
|
2008-08-28 10:10:04 +02:00
|
|
|
i0 = xscr1->i1;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
i1 = xscr1->i2;
|
|
|
|
i2 = xscr2->i2;
|
2008-08-28 10:10:04 +02:00
|
|
|
if (off > 0) {
|
|
|
|
i0 -= off;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
i1 -= off;
|
2008-08-28 10:10:04 +02:00
|
|
|
}
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
else
|
|
|
|
i2 += off;
|
2008-08-28 10:10:04 +02:00
|
|
|
chg0 = xscr1->i1 + xscr1->chg1 - i0;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
chg1 = xscr1->i2 + xscr1->chg2 - i1;
|
|
|
|
chg2 = xscr2->i2 + xscr2->chg2 - i2;
|
2008-08-29 17:16:30 +02:00
|
|
|
if (ffo < 0) {
|
2008-08-28 10:10:04 +02:00
|
|
|
chg0 -= ffo;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
chg1 -= ffo;
|
2008-08-29 17:16:30 +02:00
|
|
|
} else
|
|
|
|
chg2 += ffo;
|
2008-08-28 10:10:04 +02:00
|
|
|
if (xdl_append_merge(&c, 0,
|
|
|
|
i0, chg0, i1, chg1, i2, chg2)) {
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
xdl_cleanup_merge(changes);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
i1 = xscr1->i1 + xscr1->chg1;
|
|
|
|
i2 = xscr2->i1 + xscr2->chg1;
|
|
|
|
|
2006-12-05 22:15:35 +01:00
|
|
|
if (i1 >= i2)
|
2006-11-30 00:25:11 +01:00
|
|
|
xscr2 = xscr2->next;
|
2006-12-05 22:15:35 +01:00
|
|
|
if (i2 >= i1)
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
xscr1 = xscr1->next;
|
|
|
|
}
|
|
|
|
while (xscr1) {
|
|
|
|
if (!changes)
|
|
|
|
changes = c;
|
2008-08-28 10:10:04 +02:00
|
|
|
i0 = xscr1->i1;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
i1 = xscr1->i2;
|
|
|
|
i2 = xscr1->i1 + xe2->xdf2.nrec - xe2->xdf1.nrec;
|
2008-08-28 10:10:04 +02:00
|
|
|
chg0 = xscr1->chg1;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
chg1 = xscr1->chg2;
|
|
|
|
chg2 = xscr1->chg1;
|
2008-08-28 10:10:04 +02:00
|
|
|
if (xdl_append_merge(&c, 1,
|
|
|
|
i0, chg0, i1, chg1, i2, chg2)) {
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
xdl_cleanup_merge(changes);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
xscr1 = xscr1->next;
|
|
|
|
}
|
|
|
|
while (xscr2) {
|
|
|
|
if (!changes)
|
|
|
|
changes = c;
|
2008-08-28 10:10:04 +02:00
|
|
|
i0 = xscr2->i1;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
i1 = xscr2->i1 + xe1->xdf2.nrec - xe1->xdf1.nrec;
|
|
|
|
i2 = xscr2->i2;
|
2008-08-28 10:10:04 +02:00
|
|
|
chg0 = xscr2->chg1;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
chg1 = xscr2->chg1;
|
|
|
|
chg2 = xscr2->chg2;
|
2008-08-28 10:10:04 +02:00
|
|
|
if (xdl_append_merge(&c, 2,
|
|
|
|
i0, chg0, i1, chg1, i2, chg2)) {
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
xdl_cleanup_merge(changes);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
xscr2 = xscr2->next;
|
|
|
|
}
|
|
|
|
if (!changes)
|
|
|
|
changes = c;
|
|
|
|
/* refine conflicts */
|
xdiff: implement a zealous diff3, or "zdiff3"
"zdiff3" is identical to ordinary diff3 except that it allows compaction
of common lines on the two sides of history at the beginning or end of
the conflict hunk. For example, the following diff3 conflict:
1
2
3
4
<<<<<<
A
B
C
D
E
||||||
5
6
======
A
X
C
Y
E
>>>>>>
7
8
9
has common lines 'A', 'C', and 'E' on the two sides. With zdiff3, one
would instead get the following conflict:
1
2
3
4
A
<<<<<<
B
C
D
||||||
5
6
======
X
C
Y
>>>>>>
E
7
8
9
Note that the common lines, 'A', and 'E' were moved outside the
conflict. Unlike with the two-way conflicts from the 'merge'
conflictStyle, the zdiff3 conflict is NOT split into multiple conflict
regions to allow the common 'C' lines to be shown outside a conflict,
because zdiff3 shows the base version too and the base version cannot be
reasonably split.
Note also that the removing of lines common to the two sides might make
the remaining text inside the conflict region match the base text inside
the conflict region (for example, if the diff3 conflict had '5 6 E' on
the right side of the conflict, then the common line 'E' would be moved
outside and both the base and right side's remaining conflict text would
be the lines '5' and '6'). This has the potential to surprise users and
make them think there should not have been a conflict, but there
definitely was a conflict and it should remain.
Based-on-patch-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Co-authored-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-01 01:05:06 +01:00
|
|
|
if (style == XDL_MERGE_ZEALOUS_DIFF3) {
|
|
|
|
xdl_refine_zdiff3_conflicts(xe1, xe2, changes, xpp);
|
|
|
|
} else if (XDL_MERGE_ZEALOUS <= level &&
|
|
|
|
(xdl_refine_conflicts(xe1, xe2, changes, xpp) < 0 ||
|
|
|
|
xdl_simplify_non_conflicts(xe1, changes,
|
|
|
|
XDL_MERGE_ZEALOUS < level) < 0)) {
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
xdl_cleanup_merge(changes);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
/* output */
|
|
|
|
if (result) {
|
2010-01-17 06:30:18 +01:00
|
|
|
int marker_size = xmp->marker_size;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
int size = xdl_fill_merge_buffer(xe1, name1, xe2, name2,
|
2010-03-21 01:31:44 +01:00
|
|
|
ancestor_name,
|
2010-01-21 05:28:51 +01:00
|
|
|
favor, changes, NULL, style,
|
2010-01-17 06:30:18 +01:00
|
|
|
marker_size);
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
result->ptr = xdl_malloc(size);
|
|
|
|
if (!result->ptr) {
|
|
|
|
xdl_cleanup_merge(changes);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
result->size = size;
|
2010-03-21 01:31:44 +01:00
|
|
|
xdl_fill_merge_buffer(xe1, name1, xe2, name2,
|
|
|
|
ancestor_name, favor, changes,
|
2010-01-17 06:30:18 +01:00
|
|
|
result->ptr, style, marker_size);
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
}
|
|
|
|
return xdl_cleanup_merge(changes);
|
|
|
|
}
|
|
|
|
|
2010-03-21 01:35:18 +01:00
|
|
|
int xdl_merge(mmfile_t *orig, mmfile_t *mf1, mmfile_t *mf2,
|
|
|
|
xmparam_t const *xmp, mmbuffer_t *result)
|
|
|
|
{
|
2022-02-16 11:15:08 +01:00
|
|
|
xdchange_t *xscr1 = NULL, *xscr2 = NULL;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
xdfenv_t xe1, xe2;
|
2022-02-16 11:15:08 +01:00
|
|
|
int status = -1;
|
2010-01-17 06:01:28 +01:00
|
|
|
xpparam_t const *xpp = &xmp->xpp;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
|
|
|
|
result->ptr = NULL;
|
|
|
|
result->size = 0;
|
|
|
|
|
2022-02-16 11:15:08 +01:00
|
|
|
if (xdl_do_diff(orig, mf1, xpp, &xe1) < 0)
|
2016-02-23 12:59:17 +01:00
|
|
|
return -1;
|
2022-02-16 11:15:08 +01:00
|
|
|
|
|
|
|
if (xdl_do_diff(orig, mf2, xpp, &xe2) < 0)
|
|
|
|
goto free_xe1; /* avoid double free of xe2 */
|
|
|
|
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
if (xdl_change_compact(&xe1.xdf1, &xe1.xdf2, xpp->flags) < 0 ||
|
|
|
|
xdl_change_compact(&xe1.xdf2, &xe1.xdf1, xpp->flags) < 0 ||
|
2022-02-16 11:15:08 +01:00
|
|
|
xdl_build_script(&xe1, &xscr1) < 0)
|
|
|
|
goto out;
|
|
|
|
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
if (xdl_change_compact(&xe2.xdf1, &xe2.xdf2, xpp->flags) < 0 ||
|
|
|
|
xdl_change_compact(&xe2.xdf2, &xe2.xdf1, xpp->flags) < 0 ||
|
2022-02-16 11:15:08 +01:00
|
|
|
xdl_build_script(&xe2, &xscr2) < 0)
|
|
|
|
goto out;
|
|
|
|
|
2009-05-25 02:21:14 +02:00
|
|
|
if (!xscr1) {
|
|
|
|
result->ptr = xdl_malloc(mf2->size);
|
2022-02-16 11:15:09 +01:00
|
|
|
if (!result->ptr)
|
|
|
|
goto out;
|
|
|
|
status = 0;
|
2009-05-25 02:21:14 +02:00
|
|
|
memcpy(result->ptr, mf2->ptr, mf2->size);
|
|
|
|
result->size = mf2->size;
|
|
|
|
} else if (!xscr2) {
|
|
|
|
result->ptr = xdl_malloc(mf1->size);
|
2022-02-16 11:15:09 +01:00
|
|
|
if (!result->ptr)
|
|
|
|
goto out;
|
|
|
|
status = 0;
|
2009-05-25 02:21:14 +02:00
|
|
|
memcpy(result->ptr, mf1->ptr, mf1->size);
|
|
|
|
result->size = mf1->size;
|
|
|
|
} else {
|
2010-03-21 01:35:18 +01:00
|
|
|
status = xdl_do_merge(&xe1, xscr1,
|
|
|
|
&xe2, xscr2,
|
2010-03-01 22:46:26 +01:00
|
|
|
xmp, result);
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
}
|
2022-02-16 11:15:08 +01:00
|
|
|
out:
|
2009-05-25 02:21:14 +02:00
|
|
|
xdl_free_script(xscr1);
|
|
|
|
xdl_free_script(xscr2);
|
|
|
|
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
xdl_free_env(&xe2);
|
2022-02-16 11:15:08 +01:00
|
|
|
free_xe1:
|
|
|
|
xdl_free_env(&xe1);
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
|
2006-11-29 21:06:49 +01:00
|
|
|
return status;
|
xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-21 23:24:34 +01:00
|
|
|
}
|