Junio C Hamano [off-list ref] 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.
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