Re: Sanity checking request

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mar 28, 2007, 15:13 UTC
Message-ID: <Pine.LNX.4.64.0703280759230.6730@woody.linux-foundation.org>
In-Reply-To: <7vwt11itbz.fsf@assigned-by-dhcp.cox.net>

On Wed, 28 Mar 2007, Junio C Hamano wrote:

Show 8 quoted lines

>
> We've been saying that:
> 
> 	git read-tree -m $tree
> 
> is a quicker way to do "git read-tree $tree" (i.e. populate the
> index from a given tree), and except for the reuse of cached
> stat info to gain performance, there is no difference.

That was never technically correct. You need to use the "--reset" flag instead of "-m" if you want to just do a "git-read-tree" that also populates the index stat information.

Without "--reset", any old unmerged entries will be error cases.

Of course, when it comes to "git commit", you do *not* want to use "--reset", as erroring out when hitting an unmerged index entry is likely the right thing, even for the "git commit <paths>" case.

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.

(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?)

		Linus