Re: [PATCH v2] diff-lib.c: adjust position of i-t-a entries in diff
From: Duy Nguyen <hidden>
Date: 2016-06-15 23:04:16
On Thu, Mar 19, 2015 at 1:00 PM, Junio C Hamano [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:quoted
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