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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
