On Thu, Jun 15, 2017 at 01:33:42PM +0200, René Scharfe wrote: > Merge results need to be written to the worktree, of course, but we > don't necessarily need object entries for them, especially if they > contain conflict markers. Use pretend_sha1_file() to create fake > blobs to pass to make_cache_entry() and checkout_entry() instead. Conceptually this makes sense, although I have a comment below. Out of curiosity, did this come up when looking into the cherry-pick segfault/error from a few hours ago? > @@ -225,8 +225,8 @@ static int checkout_merged(int pos, const struct checkout *state) > * (it also writes the merge result to the object database even > * when it may contain conflicts). > */ > - if (write_sha1_file(result_buf.ptr, result_buf.size, > - blob_type, oid.hash)) > + if (pretend_sha1_file(result_buf.ptr, result_buf.size, > + OBJ_BLOB, oid.hash)) > die(_("Unable to add merge result for '%s'"), path); > free(result_buf.ptr); I wondered if pretend_sha1_file() makes a copy of the buffer, and indeed it does. So this is correct. But that raises an interesting question: how big are these objects, and is it a good idea to store them in RAM? Obviously they're in RAM already, but I'm not sure if it's one-at-a-time. We could be bumping the peak RAM used if there's a large number of these entries. Touching the on-disk odb does feel hacky, but it also means they behave like other objects. If it is a concern, I think it could be solved by "unpretending" after our call to checkout_entry completes. That would need a new call in sha1_file.c, but it should be easy to write. -Peff