summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJunio C Hamano <gitster@pobox.com>2010-01-22 00:38:56 (GMT)
committerJunio C Hamano <gitster@pobox.com>2010-01-22 01:02:30 (GMT)
commit19c6a4f8369f37c0df1fb57008a891eb6a6dc4bb (patch)
tree931a497c32219630e51ff1efc333150343333bde
parent703e6e76a14825e5b0c960d525f34e607154b4f7 (diff)
downloadgit-19c6a4f8369f37c0df1fb57008a891eb6a6dc4bb.zip
git-19c6a4f8369f37c0df1fb57008a891eb6a6dc4bb.tar.gz
git-19c6a4f8369f37c0df1fb57008a891eb6a6dc4bb.tar.bz2
merge-recursive: do not return NULL only to cause segfault
merge-recursive calls write_tree_from_memory() to come up with a virtual tree, with possible conflict markers inside the blob contents, while merging multiple common ancestors down. It is a bug to call the function with unmerged entries in the index, even if the merge to come up with the common ancestor resulted in conflicts. Otherwise the result won't be expressible as a tree object. We _might_ want to suggest the user to set GIT_MERGE_VERBOSITY to 5 and re-run the merge in the message. At least we will know which part of process_renames() or process_entry() functions is not correctly handling the unmerged paths, and it might help us diagnosing the issue. Signed-off-by: Junio C Hamano <gitster@pobox.com>
-rw-r--r--merge-recursive.c8
1 files changed, 4 insertions, 4 deletions
diff --git a/merge-recursive.c b/merge-recursive.c
index dd4fbd0..22a31ed 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -200,14 +200,14 @@ struct tree *write_tree_from_memory(struct merge_options *o)
if (unmerged_cache()) {
int i;
- output(o, 0, "There are unmerged index entries:");
+ fprintf(stderr, "BUG: There are unmerged index entries:\n");
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
if (ce_stage(ce))
- output(o, 0, "%d %.*s", ce_stage(ce),
- (int)ce_namelen(ce), ce->name);
+ fprintf(stderr, "BUG: %d %.*s", ce_stage(ce),
+ (int)ce_namelen(ce), ce->name);
}
- return NULL;
+ die("Bug in merge-recursive.c");
}
if (!active_cache_tree)