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

From: Junio C Hamano <[email-masked]>
Date: Mon, 07 Mar 2016 00:51:09 -0800

Junio C Hamano <[email-masked]> 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".