On Fri, Apr 13, 2018 at 10:39 AM, Stefan Beller <sbel...@google.com> wrote:
> Would s/read/xread/ make sense in working_tree_matches ?
Makes sense, yes.
That patch was really more of a RFD than anything that should be applied.
I would like to see the "might be same" flag pushed down so that we
don't do this comparison when it makes no sense, even if the stat info
makes that less of an issue than it might otherwise be,
And maybe that whole function should be taught to do the "verify CE
against file", and do the proper full cache state check (ie time etc)
instead of doing the read.
So maybe the best option is a combination of the two patches: my
"verify the working tree state" _together_ with the was_tracked()
logic that looks up a cache entry.
Again, the problem with "look up the index state" is about files
possibly being renamed as part of the merge, but if we then check the
index state against the actual contents of the working directory, that
isn't an issue.