On Mon, Aug 6, 2018 at 5:48 PM Junio C Hamano <gits...@pobox.com> wrote: > > I've also checked about the lookahead thing in unpack_trees() to see > > if we accidentally break something there, which is my biggest worry. > > See [1] and [2] for context, but I believe since we can't have D/F > > conflicts, the situation where lookahead is needed will not occur. So > > we should be safe. > > Isn't this about branch switching, where the currently checked out > branch may have a regular file 't' and checking out another branch > that has directory 't' in it (or vice versa, possibly with the index > having either a regular file 't' or requiring 't' to be a diretory > by having a blob 't/1' in it)?
We require the unpacked entry from all input trees to be a tree objects (the dirmask thing), so if one tree has 't' as a file, all_trees_same_as_cache_tree() should return false and not trigger this optimization. Same thing for the index, if it has the file 't', then we should not have the cache-tree at path 't' and the optimization is skipped as well. So yes branch switching definitely can have d/f conflicts, but we should never ever accidentally run this new optimization when that happens. > The log messge of [1] talks about > walking three trees together with the index, but even if we limit us > to two-tree walk, I do not think that the picture fundamentally > changes. So I am not sure how we can confidently say "we can't have > D/F". I'd need to block a solid time to take a look at the patches. Yes please :) -- Duy
