Torsten Bögershausen <tboegi@xxxxxx> writes: > The major question, at least on my side, is where to hook in > "can_clobber()" ? There are different ways the existing commands ensure that they do not lose local modifications. * Some (like unpack-trees code that is used by "merge") do refresh_cache() upfront and then ask ce_uptodate() if the contents in the working tree match the indexed contents. unpack-trees.c::verify_uptodate_1() has a call to ce_uptodate() and returns early when true (i.e. if "git add" would result in the same index entry), but then does a double-check with ie_match_stat(), which essentially asks the "does an add result in the same index entry?" again. * Others (like apply) do not do the tree-wide refresh_cache(), but asks "does an add result in the same index entry" by calling ce_match_stat(), which is a thin wrapper to ie_match_stat(), in builtin/apply.c::verify_index_match(). These places need to learn that there is a case where ie_match_stat() says "'git add' would change the index, i.e. working tree file is different" but the working tree file can still be clobbered because 'checkout' would produce the same contents in the working tree. But stepping back a bit, I no longer am sure if such a loosening is desirable. Imagine that you implemented such loosening and allowed a patch to be applied to the index (and the result checked out to the working tree). What would the result of "diff --cached" be after doing so? Would it contain only the change described in the patch you just accepted? If that is the case, it would be OK, but if the change from the patch gets mixed with the "fix incorrectly recorded data in the index" change that you would have recorded if you did "git add" from the working tree without applying the patch, then that would not be a desirable outcome, I would suspect. You would rather want to first commit the "fix incorrectly recorded data in the index" as a separate preparatory step and then want to apply the patch. So... -- 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