Re: Sanity checking request

From: Junio C Hamano <junkio@cox.net>
Date: Mar 28, 2007, 19:38 UTC
Message-ID: <7vwt11f9b9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0703280759230.6730@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 5 quoted lines

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

Show 7 quoted lines

> (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 <junkio@cox.net>
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 <junkio@cox.net>

and that is why I noticed this issue.