Re: [PATCH 4/8] read-cache: add invalidate parameter to remove_marked_cache_entries
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Dec 10, 2018, 18:19 UTC
- Message-ID
- <CACsJy8BG5ri=UMeOPqLTqxcOYqPsc9BdY4pxgQA8pfb+rE1MyA@mail.gmail.com>
- In-Reply-To
- <CABPp-BEkeRa7jOkDcNNpZMY9J9JmNGtMKjZeNv8i_u7jUFihcw@mail.gmail.com>
On Mon, Dec 10, 2018 at 7:09 PM Elijah Newren <newren@gmail.com> wrote:
Show 14 quoted lines
> > > 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.
Show 7 quoted lines
> 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