On 03/07/2016 09:51 AM, Junio C Hamano wrote:
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".
Thanks.
OK about "git add" and "git diff".
The major question, at least on my side, is where to hook in
"can_clobber()" ?
--
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