Re: fast-import's gfi_unpack_entry causes too many munmap/mmap cycles

[Mike Hommey <mh@glandium.org>]

On Sat, Apr 16, 2016 at 06:18:39PM +0900, Mike Hommey wrote:
> And even if I am okay with that overhead, I still hit the problem again
> when using that tree later with `M 040000 $sha1 ` in the next commit,
> because that does a load_tree() for the tree sha1, after a commit having
> occurred, which touched the pack, bringing me back to square one (the
> sad part being that it does so while the tree_content for the tree in
> question is already in memory).

So, interestingly, the load_tree() doesn't happen when using `from
0000000000000000000000000000000000000000\nmerge :mark` for the commit.

That is, with:
  commit refs/foo
  committer <foo@foo> 0 +0
  data 0

  M 040000 bff3a42ecae0e7c8f707d328f9432c1ffe9644b0 ""

load_tree is called. And with:
  commit refs/foo
  committer <foo@foo> 0 +0
  data 0

  from 0000000000000000000000000000000000000000
  merge :mark_of_parent
  M 040000 bff3a42ecae0e7c8f707d328f9432c1ffe9644b0 ""

it's not called.

So I think I got myself a workaround...

> A --- B
>  \
>   \-- C
> 
> I have:
> - diff between null-tree and A
> - diff between A and B
> - diff between B and C

I should be able to do:

- start the commit command for A
- before finishing it, `ls ""`
- then apply the diff for B and `ls ""`
- then apply the diff for C and `ls ""`
- then `deleteall`
- then `M 040000 sha1_from_first_ls ` and finally finish A
- create the commit for B with `from
  0000000000000000000000000000000000000000\nmerge :mark` and `M 040000
  sha1_from_second_ls`
- likewise for C

... and avoid gfi_unpack_entry.

Mike