delta/git.git/xdiff/xmerge.c, branch hv/mv-nested-submodules-test

Merge branch 'ps/plug-xdl-merge-leak'

2016-02-26T21:37:22+00:00

* ps/plug-xdl-merge-leak:
  xdiff/xmerge: fix memory leak in xdl_merge

xdiff/xmerge: fix memory leak in xdl_merge

2016-02-23T20:58:26+00:00

When building the script for the second file that is to be merged
we have already allocated memory for data structures related to
the first file. When we encounter an error in building the second
script we only free allocated memory related to the second file
before erroring out.

Fix this memory leak by also releasing allocated memory related
to the first file.

Helped-by: Johannes Schindelin 
Signed-off-by: Patrick Steinhardt 
Signed-off-by: Junio C Hamano

merge-file: ensure that conflict sections match eol style

2016-01-27T18:21:53+00:00

In the previous patch, we made sure that the conflict markers themselves
match the end-of-line style of the input files. However, this still left
out the conflicting text itself: if it lacks a trailing newline, we
add one, and should add a carriage return when appropriate, too.

Signed-off-by: Johannes Schindelin 
Signed-off-by: Junio C Hamano

merge-file: let conflict markers match end-of-line style of the context

2016-01-27T18:21:26+00:00

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 
Signed-off-by: Junio C Hamano

git-merge-file: do not add LF at EOF while applying unrelated change

2014-06-30T21:07:58+00:00

If 'current-file' does not contain LF at EOF, and change between
'base-file' and 'other-file' does not change any line close to EOF, the
3-way merge should not add LF to EOF.  This is what 'diff3 -m' does, and
seems to be a reasonable expectation.

The change which introduced the behavior is cd1d61c44f. It always calls
function xdl_recs_copy() for sides with add_nl == 1. In fact, it looks
like the only case when this is needed is when 2 files are being
union-merged, and they do not have LF at EOF (strictly speaking, the
first of them).

Add tests:
* "merge without conflict (missing LF at EOF, away from change in the
other file)" and "merge does not add LF away of change", to demonstrate
the changed behavior.
* "conflict at EOF without LF resolved by --union", to verify that the
union-merge at the end inerts newline between versions.
* some more tests which I felt like not covering the functionality well

Signed-off-by: Max Kirillov 
Acked-by: Johannes Schindelin 
Signed-off-by: Junio C Hamano

xdiff: cast arguments for ctype functions to unsigned char

2010-10-06T17:46:45+00:00

The ctype functions isspace(), isalnum(), et al take an integer
argument representing an unsigned character, or -1 for EOF.  On
platforms with a signed char, it is unsafe to pass a char to them
without casting it to unsigned char first.

Most of git is already shielded against this by the ctype
implementation in git-compat-util.h, but xdiff, which uses libc
ctype.h, ought to be fixed.

Noticed-by: der Mouse 
Reported-by: Ævar Arnfjörð Bjarmason 
Signed-off-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

xdiff/xmerge.c: use memset() instead of explicit for-loop

2010-05-01T18:11:11+00:00

memset() is heavily optimized, and resulting assembler code
is about 150 lines less for that file.

Signed-off-by: Alexey Mahotkin 
Signed-off-by: Junio C Hamano

xdl_merge(): move file1 and file2 labels to xmparam structure

2010-03-21T03:36:10+00:00

The labels for the three participants in a potential conflict are all
optional arguments for the xdiff merge routine; if they are NULL, then
xdl_merge() can cope by omitting the labels from its output.  Move
them to the xmparam structure to allow new callers to save some
keystrokes where they are not needed.

This also has the virtue of making the xdiff merge interface more
similar to merge_trees, which might make it easier to learn.

Signed-off-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

xdl_merge(): add optional ancestor label to diff3-style output

2010-03-21T03:36:10+00:00

The ‘git checkout --conflict=diff3’ command can be used to
present conflicts hunks including text from the common ancestor:

	<<<<<<< ours
	ourside
	|||||||
	original
	=======
	theirside
	>>>>>>> theirs

The added information is helpful for resolving merges by hand, and
merge tools can usually grok it because it is very similar to the
output from diff3 -m.

A subtle change can help more tools to understand the output.  ‘diff3’
includes the name of the merge base on the ||||||| line of the output,
and some tools misparse the conflict hunks without it.  Add a new
xmp->ancestor parameter to xdl_merge() for use with conflict style
XDL_MERGE_DIFF3 as a label on the ||||||| line for any conflict hunks.

If xmp->ancestor is NULL, the output format is unchanged.  Thus, this
change only provides unexposed plumbing for the new feature; it does
not affect the outward behavior of git.

Requested-by: Stefan Monnier 
Signed-off-by: Jonathan Nieder 
Acked-by: Bert Wesarg 
Signed-off-by: Junio C Hamano

refactor merge flags into xmparam_t

2010-03-02T19:51:48+00:00

Include the merge level, favor, and style flags into the xmparam_t struct.
This removes the bit twiddling with these three values into the one flags
parameter.

Signed-off-by: Bert Wesarg 
Signed-off-by: Junio C Hamano