On Mon, 2014-07-14 at 15:16 -0700, Junio C Hamano wrote: > Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxx> writes: > > > On 14/07/14 18:51, Junio C Hamano wrote: > >> Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxx> writes: > >> > >>> that the merge commit 7608c87e fails. Looking at the details of the > >>> merge resolution, made me think of Duy's split index work. > >> > >> Yes, there is a deliberately dropped hunk from dt/cache-tree-repair > >> in that merge, because the topic relied on being able to say "here > >> is the file descriptor, write the index to it", which no longer is > >> available with the split-index topic. > > > > Ah, OK. Sounds like everything is under control then. > > Wasn't, but now I think it is ;-) > > David, could you please double check the conflict resolution at > 882426ea (Merge branch 'dt/cache-tree-repair' into jch, 2014-07-14), > at about the middle between master..pu? By eyeballing > > git diff 882426ea^ 882426ea > > we should see what your series would have done if it were based on > top of the nd/split-index topic. The most iffy is the first hunk of > change to builtin/commit.c, which is more or less my rewrite of what > you did on top of 'master'. LGTM. And the tests all pass. > The change to builtin/checkout.c also seems somewhat iffy in that we > treat the_index.cache_tree (aka "active_cache_tree") as if cache > trees are something we can manipulate independent of a particular > index_state (which has been the rule for a long time), even though > in the world order after nd/split-index topic, cache_tree_update() > can no longer be used on a cache-tree that is not associated to a > particular index_state. It is not a problem with your series, but > comes from nd/split-index topic, and it might indicate a slight > unevenness of the API (i.e. we may want to either insist that the > public API to muck with a cache-tree outside cache-tree.c must be > accessed via an index-state and never via a bare cache-tree > structure, by insisting that cache_tree_fully_valid() to take a > pointer to an index-state as well; or we may want to go the other > way and allow API users to pass a bare cache-tree without the > index-state when the latter is not absolutely necessary, by changing > cache_tree_update() to take a cache-tree, not an index-state). I agree that some sort of API updates like would be an improvement. But this seems to work for now. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html