On Wed, 28 Mar 2007, Junio C Hamano wrote: > > 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 - 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