Re: Sanity checking request

Linus Torvalds [off-list ref] writes:

That said, I actually think the newer "git read-tree -m" behaviour makes 
sense. So I think we're much better off adding "-i" to git-commit.sh, than 
to force "-i" on when doing the one-way merge. The latter change just 
effectively disables a possible check entirely, the former at least allows 
other users to actually use that form if they ever want to.

Thanks, I agree.

(Looking at git-commit.sh, the thing I *really* think we should do is to 
have a "GIT_INDEX_FILE_OUTPUT" environment variable that does locking on 
the input file, but writes the result to another file: rigth now 
git-commit.sh (a) wastes time copying the old index file by hand and (b) 
as a result doesn't even honor any locking on it. I think whether it uses 
"-i" or not is actually less important - if you commit only a subset of 
files, maybe the extra checks in git-read-tree are actually ok?)

Good point on locking.

The reason missing -i matters because it defeats the previous
158d0577:

commit 158d0577891441c01457bbcaf45585d3b50f5d75
Author: Junio C Hamano [off-list ref]
Date:   Sat Dec 9 22:32:43 2006 -0800

    git-commit: allow --only to lose what was staged earlier.
    
    The command used to have a safety valve to prevent this sequence:
    
    	edit foo
    	git update-index foo
    	edit foo
    	git diff foo
    	git commit --only foo
    
    The reason for this was because an inexperienced user might
    mistakenly think what is shown with the last-minute diff
    contains all the change that is being committed (instead, what
    the user asked to check was an incremental diff since what has
    been staged so far).  However, this turns out to only annoy
    people who know what they are doing.  Inexperienced people
    would not be using the first "update-index" anyway, in which
    case they would see the full changes in the "git diff".
    
    Signed-off-by: Junio C Hamano [off-list ref]

and that is why I noticed this issue.