On Thu, Mar 19, 2015 at 1:00 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Ah, wait. >> >> I suspect that it all cancels out. >> ... >> Now, as you mentioned, there _may_ be codepaths that uses the same >> definition of "what's in the index" as what diff-cache used to take >> before your patches, and they may be broken by removing the >> invalidation. If we find such codepaths, we should treat their old >> behaviour as buggy and fix them, instead of reintroducing the >> invalidation and keep their current behaviour, as the new world >> order is "i-t-a entries in the index does not yet exist." > > One potential negative consequence of the new world order I can > immediately think of is this. In many operations, we try to be > lenient to changes in the working tree as long as the index is > clean. "read-tree -m" is the most visible one, where we require > that the index and HEAD matches while allowing changes to working > tree paths as long as they do not interfere with the paths that are > involved in the merge. We need to make sure that the path dir/bar > added by "add -N dir/bar", which in the new world order does not > count as "index is not clean and there is a difference from HEAD", > (1) does not interfere with the mergy operation that wants to touch > dir (which _could_ even be expected to be a file) or dir/bar, and > (2) is not lost because the mergy operation wants to touch dir or > dir/bar, for example. "read-tree -m" does not invoke diff, does it? If I went with my previous approach (modifying unpack-trees to ignore i-t-a entries) then this could be a problem, but because unpack-trees is untouched, merge operations should not be impacted by this patch. Even if some other command does "diff --cached" first to abort early, if "diff --cached" fails to report "HEAD and index are different" as you described, I would expect unpack-trees to be able to deal with it anyway. PS. Sorry for the late response, busy fighting the evil last weekend. I blame Steam on Linux. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html