On Mon, Dec 10, 2018 at 7:09 PM Elijah Newren <newren@xxxxxxxxx> wrote: > > > For the two current callsites, unpack-trees seems to do this > > > invalidation itself internally. > > > > I'm still a bit scared of this invalidation business in unpack-trees. > > The thing is, we handle two separate index_state there, src_index and > > result and invalidation has to be done on the right one (because index > > extensions are on src_index until the very end of unpack-trees; > > invalidating on 'result' would be no-op and wrong). > > remove_marked_cache_entries() seems to be called on 'result' while > > invalidate_ce_path() is on src_index, hm.... > > Is Thomas avoiding problems here simply because merge is the only > caller of unpack_trees with src_index != dst_index? Or does src_index > == dst_index for checkout not actually help? I think it would not help. 'result' is a temporary index where we copy things to (and it does not have anything from the beginning). If you invalidate stuff in there, you invalidate nothing, regardless whether dst_index == src_index. > If that does help with the checkout case, then allow me to find a > different way to muddy the waters... I think I might want to make use > of this function in the merge machinery at some point, so I either > need to figure out how to convince you to verify if all this cache > tree invalidation stuff is sane, or somehow figure out all the > cache_tree stuff stuff myself so I can figure out what is right here. > :-) I'm not the unpack-trees man (I think that would still be Junio). And I'm not saying it's sane either. I think it's just some leftover things since Linus split "the index" in unpack-tree operation to 'src', 'result' and 'dst' many years ago and nobody was brave enough to clean it up (then I piled on with untracked cache and split index, but I did not see it clearly either). That person could be you ;-) -- Duy
