Junio C Hamano <gitster@xxxxxxxxx> writes: > Perhaps we can introduce a new function can_clobber() that has the > same function signature as ce_uptodate() and update the callers in > apply and unpack-trees (there may be others) to call it instead when > they want to see if they can clobber the working tree file that > corresponds to the cache entry. By the way, I do not want see ie_match_stat() modified to work like the can_clobber() I outlined in the previous message, which in turn means that immediately after "git reset --hard" or "git checkout" when your convert_to_git() and convert_to_working_tree() do not roundtrip, you _must_ see differences in "git diff". This is for (at least) two reasons. * "git diff" (compare between the index and the working tree) is meant as a preview of how the indexed contents will be modified if you did "git add" with what you currently have in your working tree at the path. In a "conversions do not roundtrip" situation, your "git add" will be modifying the contents in the index, so we should actively be showing what modification we will be making. One way of "fixing" the situation without changing either the working tree contents or the indexed contents is to fix your convert-to-git settings to make the conversions round-trip, and then you would stop seeing the changes you would make when you do "git add". Not showing any diff when can_clobber() is true but ce_uptodate() is false would make "git diff" less useful when the user makes this correction. * "git add" of a path can legitimately optimize itself by not adding a path that is ce_uptodate(). Mixing ie_match_stat() with can_clobber() logic would mark such a "conversions do not roundtrip" path as ce_uptodate(), and prevent the user from "fixing" the incorrect index entry by running "git add". -- 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