Tim Olsen <tim@xxxxxxxxxxxxxxxxxxx> writes:
> The following happens on 1.6.6 and master as of
> 5b15950ac414a8a2d4f5eb480712abcc9fe176d2. The problem goes away if I
> use the resolve merge strategy instead.
Thanks.
Since you can build and run git yourself, can I ask you to run another
experiment with this one-liner patch applied?
diff --git a/builtin-merge.c b/builtin-merge.c
index 82e2a04..08a8f24 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -550,7 +550,7 @@ static int try_merge_strategy(const char *strategy, struct commit_list *common,
return error("Unable to write index.");
rollback_lock_file(lock);
- if (!strcmp(strategy, "recursive") || !strcmp(strategy, "subtree")) {
+ if (0) {
int clean;
struct commit *result;
struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
This disables the codepath that special-cases the calling convention for
these merge strategies, and was introduce by 18668f5 (builtin-merge: avoid
run_command_v_opt() for recursive and subtree, 2008-08-28 -- authors Cc'ed
to ask for help in diagnosing).
If this experiment "fixes" the failure for you, then it would be a sign
that the caller (not necessarily in the code in this "if()" block) may be
doing something wrong (or more likely, not doing enough) before calling
into merge_recursive(). I am suspecting that it is not parsing some
commit objects properly, e.g. using lookup_commit(SHA-1) and using the
result without calling parse_object() on it first, or something similar
that is silly but trivial to fix.
After the experiment, please revert the above one-liner. I don't want to
use a work-around forever; we'd be better off finding where in the code it
goes wrong. Looking at your gdb trace, I notice...
> (gdb) r
> Starting program: /usr/local/bin/git merge origin/deployed
> [Thread debugging using libthread_db enabled]
> ...
> #3 0x0000000000499523 in merge_trees (o=0x7fffffffd5b0, head=0x77b058,
> merge=0x77b030, common=0x0, result=0x7fffffffd548) at merge-recursive.c:1209
> code = 8076320
> clean = 13064
"common = NULL" means merged_common_ancestors->tree is NULL in the caller.
Somebody is passing a bogus commit in "ca" (aka common ancestors) list
when calling merge_recursive(), or forgetting to parse them before calling
it. In your debugger could you find out where it comes from and what it
has before this call into merge_trees() is made? Specifically, what the
"ca" list at 0x7b3c00 contains, and how "merged_common_ancestors" at
0x121e360 looks like. in this trace we see below:
> #4 0x0000000000499a46 in merge_recursive (o=0x7fffffffd5b0,
> h1=0x7932d0, h2=0x793240, ca=0x7b3c00, result=0x7fffffffd628) at
> merge-recursive.c:1343
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html