1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-04-28 08:35:23 +02:00
git/merge-blobs.c

105 lines
2.2 KiB
C
Raw Permalink Normal View History

#include "git-compat-util.h"
merge-ll: rename from ll-merge A long term (but rather minor) pet-peeve of mine was the name ll-merge.[ch]. I thought it made it harder to realize what stuff was related to merging when I was working on the merge machinery and trying to improve it. Further, back in d1cbe1e6d8a ("hash-ll.h: split out of hash.h to remove dependency on repository.h", 2023-04-22), we have split the portions of hash.h that do not depend upon repository.h into a "hash-ll.h" (due to the recommendation to use "ll" for "low-level" in its name[1], but which I used as a suffix precisely because of my distaste for "ll-merge"). When we discussed adding additional "*-ll.h" files, a request was made that we use "ll" consistently as either a prefix or a suffix. Since it is already in use as both a prefix and a suffix, the only way to do so is to rename some files. Besides my distaste for the ll-merge.[ch] name, let me also note that the files ll-fsmonitor.h, ll-hash.h, ll-merge.h, ll-object-store.h, ll-read-cache.h would have essentially nothing to do with each other and make no sense to group. But giving them the common "ll-" prefix would group them. Using "-ll" as a suffix thus seems just much more logical to me. Rename ll-merge.[ch] to merge-ll.[ch] to achieve this consistency, and to ensure we get a more logical grouping of files. [1] https://lore.kernel.org/git/kl6lsfcu1g8w.fsf@chooglen-macbookpro.roam.corp.google.com/ Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-16 08:34:04 +02:00
#include "merge-ll.h"
#include "blob.h"
#include "merge-blobs.h"
#include "object-store-ll.h"
static int fill_mmfile_blob(mmfile_t *f, struct blob *obj)
{
void *buf;
unsigned long size;
enum object_type type;
buf = repo_read_object_file(the_repository, &obj->object.oid, &type,
&size);
if (!buf)
return -1;
if (type != OBJ_BLOB) {
free(buf);
return -1;
}
f->ptr = buf;
f->size = size;
return 0;
}
static void free_mmfile(mmfile_t *f)
{
free(f->ptr);
}
static void *three_way_filemerge(struct index_state *istate,
const char *path,
mmfile_t *base,
mmfile_t *our,
mmfile_t *their,
unsigned long *size)
{
enum ll_merge_result merge_status;
mmbuffer_t res;
/*
* This function is only used by cmd_merge_tree, which
* does not respect the merge.conflictstyle option.
* There is no need to worry about a label for the
* common ancestor.
*/
merge_status = ll_merge(&res, path, base, NULL,
our, ".our", their, ".their",
istate, NULL);
if (merge_status < 0)
return NULL;
if (merge_status == LL_MERGE_BINARY_CONFLICT)
warning("Cannot merge binary files: %s (%s vs. %s)",
path, ".our", ".their");
*size = res.size;
return res.ptr;
}
void *merge_blobs(struct index_state *istate, const char *path,
struct blob *base, struct blob *our,
struct blob *their, unsigned long *size)
{
void *res = NULL;
mmfile_t f1, f2, common;
/*
* Removed in either branch?
*
* NOTE! This depends on the caller having done the
* proper warning about removing a file that got
* modified in the other branch!
*/
if (!our || !their) {
enum object_type type;
if (base)
return NULL;
if (!our)
our = their;
return repo_read_object_file(the_repository, &our->object.oid,
&type, size);
}
if (fill_mmfile_blob(&f1, our) < 0)
goto out_no_mmfile;
if (fill_mmfile_blob(&f2, their) < 0)
goto out_free_f1;
if (base) {
if (fill_mmfile_blob(&common, base) < 0)
goto out_free_f2_f1;
} else {
common.ptr = xstrdup("");
common.size = 0;
}
res = three_way_filemerge(istate, path, &common, &f1, &f2, size);
free_mmfile(&common);
out_free_f2_f1:
free_mmfile(&f2);
out_free_f1:
free_mmfile(&f1);
out_no_mmfile:
return res;
}