On Mon, Sep 17, 2018 at 10:09 AM Junio C Hamano <gits...@pobox.com> wrote: > > It usually is safer (simply because you do not have to think about > it) to start a behaviour change like this as a strict opt-in to gain > confidence.
I tend to agree, however.. in this case it could be considered safer to err on the side of not throwing away the index which could have crafted changes in it. > The approach to check if the contents in the index matches that in > the HEAD per-path (i.e. "The contents we are adding to the index is > whole working tree contents for that path. But the index already > has contents different from HEAD for the path---are we losing > information by doing this?"), is a very good one. But for the > protection to be effective, I think "git commit" and "git add" > should be covered the same way, ideally with the same code and > possibly the same configuration knob and/or command line option to > control the behaviour. Checking both commit and add makes sense to me. > > If the information loss caused by the "add/commit X" or "add > -u/commit -a" is so serious that this new feature deserves to become > the default (which I do not yet think it is the case, by the way), > then we could even forbid "commit X" or "commit -a" when the paths > involved has difference between the index and the HEAD, without any > configuration knob or command line override for "commit", and then > tell the users to use "git add/rm" _with_ the override before coming > back to "git commit". I was going to suggest we have some sort of reflog equivalent for the index, but Duy seems to discuss that in a follow-on mail. > > How should this new check intract with paths added with "add -N", by > the way?
