@@ -17,6 +17,8 @@
#include "cache.h"
#include "merge-ort.h"
+#include "diff.h"
+#include "diffcore.h"
#include "strmap.h"
#include "tree.h"
@@ -107,7 +109,47 @@ void merge_finalize(struct merge_options *opt,
static void merge_start(struct merge_options *opt, struct merge_result *result)
{
- die("Not yet implemented.");
+ /* Sanity checks on opt */
+ assert(opt->repo);
+
+ assert(opt->branch1 && opt->branch2);
+
+ assert(opt->detect_directory_renames >= MERGE_DIRECTORY_RENAMES_NONE &&
+ opt->detect_directory_renames <= MERGE_DIRECTORY_RENAMES_TRUE);
+ assert(opt->rename_limit >= -1);
+ assert(opt->rename_score >= 0 && opt->rename_score <= MAX_SCORE);
+ assert(opt->show_rename_progress >= 0 && opt->show_rename_progress <= 1);
+
+ assert(opt->xdl_opts >= 0);
+ assert(opt->recursive_variant >= MERGE_VARIANT_NORMAL &&
+ opt->recursive_variant <= MERGE_VARIANT_THEIRS);
+
+ /*
+ * detect_renames, verbosity, buffer_output, and obuf are ignored
+ * fields that were used by "recursive" rather than "ort" -- but
+ * sanity check them anyway.
+ */
+ assert(opt->detect_renames >= -1 &&
+ opt->detect_renames <= DIFF_DETECT_COPY);
+ assert(opt->verbosity >= 0 && opt->verbosity <= 5);
+ assert(opt->buffer_output <= 2);
+ assert(opt->obuf.len == 0);
+
+ assert(opt->priv == NULL);
+
+ /* Initialization of opt->priv, our internal merge data */
+ opt->priv = xcalloc(1, sizeof(*opt->priv));
+ /*
+ * Although we initialize opt->priv->paths with strdup_strings=0,
+ * that's just to avoid making yet another copy of an allocated
+ * string. Putting the entry into paths means we are taking
+ * ownership, so we will later free it.
+ *
+ * In contrast, unmerged just has a subset of keys from paths, so
+ * we don't want to free those (it'd be a duplicate free).
+ */
+ strmap_ocd_init(&opt->priv->paths, NULL, 0);
+ strmap_ocd_init(&opt->priv->unmerged, NULL, 0);
}
/*
merge_start() basically does a bunch of sanity checks, then allocates and initializes opt->priv -- a struct merge_options_internal. Most 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 <newren@gmail.com> --- merge-ort.c | 44 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 43 insertions(+), 1 deletion(-)