git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Sanity checking request
@ 2007-03-28  9:57 Junio C Hamano
  2007-03-28 15:13 ` Linus Torvalds
  0 siblings, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2007-03-28  9:57 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: git

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

^ permalink raw reply related	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2007-04-01 16:08 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-03-28  9:57 Sanity checking request Junio C Hamano
2007-03-28 15:13 ` Linus Torvalds
2007-03-28 19:38   ` Junio C Hamano
2007-04-01  6:27   ` [PATCH 0/2] Alternate index output file Junio C Hamano
2007-04-01  6:29     ` [PATCH 1/2] _GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file Junio C Hamano
2007-04-01  6:29     ` [PATCH 2/2] git-read-tree --index-output=<file> Junio C Hamano
2007-04-01 16:08     ` [PATCH 0/2] Alternate index output file Linus Torvalds

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).