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

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

On 03/07/2016 09:51 AM, Junio C Hamano wrote:

Junio C Hamano [off-list ref] writes:

quoted

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".

Thanks.
OK about "git add" and "git diff".
The major question, at least on my side, is where to hook in 
"can_clobber()" ?