summaryrefslogtreecommitdiff
path: root/merge-blobs.c
AgeCommit message (Collapse)AuthorFilesLines
2016-02-26Merge branch 'jk/no-diff-emit-common'Libravatar Junio C Hamano1-36/+2
"git merge-tree" used to mishandle "both sides added" conflict with its own "create a fake ancestor file that has the common parts of what both sides have added and do a 3-way merge" logic; this has been updated to use the usual "3-way merge with an empty blob as the fake common ancestor file" approach used in the rest of the system. * jk/no-diff-emit-common: xdiff: drop XDL_EMIT_COMMON merge-tree: drop generate_common strategy merge-one-file: use empty blob for add/add base
2016-02-22merge-tree: drop generate_common strategyLibravatar Jeff King1-36/+2
When merge_blobs sees an add/add conflict, it tries to create a virtual base object for the 3-way merge that consists of the common lines of each file. It inherited this strategy from merge-one-file in 0c79938 (Improved three-way blob merging code, 2006-06-28), and the point is to minimize the size of the conflict hunks. That commit talks about "if libxdiff were to ever grow a compatible three-way merge, it could probably be directly plugged in". That has long since happened. So as with merge-one-file in the previous commit, this extra step is no longer necessary. Our 3-way merge code is smart enough to do the minimizing itself if we simply feed it an empty base, which is what the more modern merge-recursive strategy already does. Not only does this let us drop some code, but it removes an overflow bug in generate_common_file(). We allocate a buffer as large as the smallest of the two blobs, under the assumption that there cannot be more common content than what is in the smaller blob. However, xdiff may feed us more: if neither file ends in a newline, it feeds us the "\nNo newline at end of file" marker as common content, and we write it into the output. If the differences between the files are small than that string, we overflow the output buffer. This patch solves it by simply dropping the buggy code entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-20Remove get_object_hash.Libravatar brian m. carlson1-2/+2
Convert all instances of get_object_hash to use an appropriate reference to the hash member of the oid member of struct object. This provides no functional change, as it is essentially a macro substitution. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20Add several uses of get_object_hash.Libravatar brian m. carlson1-2/+2
Convert most instances where the sha1 member of struct object is dereferenced to use get_object_hash. Most instances that are passed to functions that have versions taking struct object_id, such as get_sha1_hex/get_oid_hex, or instances that can be trivially converted to use struct object_id instead, are not converted. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-03-23merge-blobs.c: fix a memleakLibravatar Stefan Beller1-1/+3
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-09Which merge_file() function do you mean?Libravatar Junio C Hamano1-0/+124
There are two different static functions and one global function, all of them called "merge_file()", with different signatures and purposes. Rename them all to reduce confusion in "git grep" output: * Rename the static one in merge-index to "merge_one_path(const char *path)" as that function is about asking an external command to resolve conflicts in one path. * Rename the global one in merge-file.c that is only used by merge-tree to "merge_blobs()", as the function takes three blobs and returns the merged result only in-core, without doing anything to the filesystem. * Rename the one in merge-recursive to "merge_one_file()", just to be fair. Also rename merge-file.[ch] to merge-blobs.[ch]. Signed-off-by: Junio C Hamano <gitster@pobox.com>