Subject: Re: [PATCH 1/3] git reset --hard gives clean working tree

From: Junio C Hamano <[email-masked]>
Date: Mon, 07 Mar 2016 14:34:26 -0800

Torsten Bögershausen <[email-masked]> 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...