rerere: do not leak mmfile[] for a path with multiple stage #1 entries

A conflicted index can have multiple stage #1 entries when dealing
with a criss-cross merge and using the "resolve" merge strategy.

Plug the leak by reading only the first one of the same stage
entries.

Strictly speaking, this fix does change the semantics, in that we
used to use the last stage #1 entry as the common ancestor when
doing the plain-vanilla three-way merge, but with the leak fix, we
will use the first stage #1 entry.  But it is not a grave backward
compatibility breakage.  Either way, we are arbitrarily picking one
of multiple stage #1 entries and using it, ignoring others, and
there is no meaning in the ordering of these stage #1 entries.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/rerere.c b/rerere.c
index e1d527c2506a461687ec89421f08b2de355dd10a..d665debf0f2a0ccc23d92c263f5a895442465442 100644 (file)
--- a/rerere.c
+++ b/rerere.c
@@ -337,8 +337,10 @@ static int handle_cache(const char *path, unsigned char *sha1, const char *outpu
                if (ce_namelen(ce) != len || memcmp(ce->name, path, len))
                        break;
                i = ce_stage(ce) - 1;
-               mmfile[i].ptr = read_sha1_file(ce->sha1, &type, &size);
-               mmfile[i].size = size;
+               if (!mmfile[i].ptr) {
+                       mmfile[i].ptr = read_sha1_file(ce->sha1, &type, &size);
+                       mmfile[i].size = size;
+               }
        }
        for (i = 0; i < 3; i++)
                if (!mmfile[i].ptr && !mmfile[i].size)