Skip to content

Commit e4171b1

Browse files
newrengitster
authored andcommitted
merge-ort: port merge_start() from merge-recursive
merge_start() basically does a bunch of sanity checks, then allocates and initializes opt->priv -- a struct merge_options_internal. Most of the sanity checks are usable as-is. The allocation/intialization is a bit different since merge-ort has a very different merge_options_internal than merge-recursive, but the idea is the same. The weirdest part here is that merge-ort and merge-recursive use the same struct merge_options, even though merge_options has a number of fields that are oddly specific to merge-recursive's internal implementation and don't even make sense with merge-ort's high-level design (e.g. buffer_output, which merge-ort has to always do). I reused the same data structure because: * most the fields made sense to both merge algorithms * making a new struct would have required making new enums or somehow externalizing them, and that was getting messy. * it simplifies converting the existing callers by not having to have different code paths for merge_options setup. I also marked detect_renames as ignored. We can revisit that later, but in short: merge-recursive allowed turning off rename detection because it was sometimes glacially slow. When you speed something up by a few orders of magnitude, it's worth revisiting whether that justification is still relevant. Besides, if folks find it's still too slow, perhaps they have a better scaling case than I could find and maybe it turns up some more optimizations we can add. If it still is needed as an option, it is easy to add later. Signed-off-by: Elijah Newren <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 231e2dd commit e4171b1

File tree

1 file changed

+44
-1
lines changed

1 file changed

+44
-1
lines changed

merge-ort.c

Lines changed: 44 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,8 @@
1717
#include "cache.h"
1818
#include "merge-ort.h"
1919

20+
#include "diff.h"
21+
#include "diffcore.h"
2022
#include "strmap.h"
2123
#include "tree.h"
2224

@@ -215,7 +217,48 @@ void merge_finalize(struct merge_options *opt,
215217

216218
static void merge_start(struct merge_options *opt, struct merge_result *result)
217219
{
218-
die("Not yet implemented.");
220+
/* Sanity checks on opt */
221+
assert(opt->repo);
222+
223+
assert(opt->branch1 && opt->branch2);
224+
225+
assert(opt->detect_directory_renames >= MERGE_DIRECTORY_RENAMES_NONE &&
226+
opt->detect_directory_renames <= MERGE_DIRECTORY_RENAMES_TRUE);
227+
assert(opt->rename_limit >= -1);
228+
assert(opt->rename_score >= 0 && opt->rename_score <= MAX_SCORE);
229+
assert(opt->show_rename_progress >= 0 && opt->show_rename_progress <= 1);
230+
231+
assert(opt->xdl_opts >= 0);
232+
assert(opt->recursive_variant >= MERGE_VARIANT_NORMAL &&
233+
opt->recursive_variant <= MERGE_VARIANT_THEIRS);
234+
235+
/*
236+
* detect_renames, verbosity, buffer_output, and obuf are ignored
237+
* fields that were used by "recursive" rather than "ort" -- but
238+
* sanity check them anyway.
239+
*/
240+
assert(opt->detect_renames >= -1 &&
241+
opt->detect_renames <= DIFF_DETECT_COPY);
242+
assert(opt->verbosity >= 0 && opt->verbosity <= 5);
243+
assert(opt->buffer_output <= 2);
244+
assert(opt->obuf.len == 0);
245+
246+
assert(opt->priv == NULL);
247+
248+
/* Initialization of opt->priv, our internal merge data */
249+
opt->priv = xcalloc(1, sizeof(*opt->priv));
250+
251+
/*
252+
* Although we initialize opt->priv->paths with strdup_strings=0,
253+
* that's just to avoid making yet another copy of an allocated
254+
* string. Putting the entry into paths means we are taking
255+
* ownership, so we will later free it.
256+
*
257+
* In contrast, conflicted just has a subset of keys from paths, so
258+
* we don't want to free those (it'd be a duplicate free).
259+
*/
260+
strmap_init_with_options(&opt->priv->paths, NULL, 0);
261+
strmap_init_with_options(&opt->priv->conflicted, NULL, 0);
219262
}
220263

221264
/*

0 commit comments

Comments
 (0)