Sanity checking request

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.

Well, I think I broke it with fcc387d on May 17 2006, and I am
wondering what the correct way to fix that should be.  It
depends on how -u and -i options to git-read-tree are meant to
be used.

On one hand, one could argue that "git read-tree -m $tree"
should behave the same way as "git read-tree -m -u $tree" except
that it does not do the checkout part.  The in-code comment for
the -i option says "a merge will not even look at the working
tree", implying that it will without the option, so running
verify_update() and verify_absense() even though update option
is not explicitly passed (hence read-tree itself does not do the
checkout) might be the right thing to do.  Admittedly, when I
introduced the above breakage, I wasn't consciously making such
design decision (I was more interested in making two- and
three-tree case work).  Then "git read-tree -i -m $tree" would
become the new right way to do a quicker "git read-tree $tree"
if we take this route.

The only in-tree user of single-tree merge is in git-commit.  We
could do this:

diff --git a/git-commit.sh b/git-commit.sh
index 3656d60..292cf96 100755
--- a/git-commit.sh
+++ b/git-commit.sh

@@ -371,7 +371,7 @@ t,)
 		if test -z "$initial_commit"
 		then
 			cp "$THIS_INDEX" "$TMP_INDEX"
-			GIT_INDEX_FILE="$TMP_INDEX" git-read-tree -m HEAD
+			GIT_INDEX_FILE="$TMP_INDEX" git-read-tree -i -m HEAD
 		else
 			rm -f "$TMP_INDEX"
 		fi || exit

Alternatively, we could make -i implied for one-tree merge
unless -u is given, which is the attached.

What do you think?

-- >8 --
read-tree -m $TREE: do not look at working tree.

A merging single-tree read-tree has been advertised as a quicker
way to do the equivalent single-tree read-tree without any other
difference, but currently it looks at the working tree and does
bogus checks to detect if the paths have local changes and
such.  Disable them.

Signed-off-by: Junio C Hamano <redacted>
---

diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 793eae0..2a1d3c8 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c

@@ -236,6 +236,8 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
 		switch (stage - 1) {
 		case 1:
 			opts.fn = opts.prefix ? bind_merge : oneway_merge;
+			if (!opts.update)
+				opts.index_only = 1;
 			break;
 		case 2:
 			opts.fn = twoway_merge;

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