Re: [PATCH v8 4/4] cache-tree: Write updated cache-tree after commit

[David Turner <dturner@twopensource.com>]

On Mon, 2014-07-14 at 15:16 -0700, Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> 
> > On 14/07/14 18:51, Junio C Hamano wrote:
> >> Ramsay Jones <ramsay@ramsay1.demon.co.uk> 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.