threads / patch / 6138

patch, 11 partsHonor GIT_REFLOG_ACTION in git-rebase.

Subject: [PATCH 2/11] Honor GIT_REFLOG_ACTION in git-rebase.

## tl;dr

17 messages between Dec 28, 2006 and Dec 29, 2006. Diffs are folded; open one to read it.

replies: 16people: 3as markdown or json

Shawn O. Pearce· Dec 28, 2006, 07:34 UTC · lore

To help correctly log actions caused by porcelain which invoke git-reset directly we should honor the setting of GIT_REFLOG_ACTION which we inherited from our caller.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 git-reset.sh |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
Show changes to git-reset.sh +2 −1
diff --git a/git-reset.sh b/git-reset.sh
index 2379db0..a969370 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -5,6 +5,7 @@
 USAGE='[--mixed | --soft | --hard]  [<commit-ish>] [ [--] <paths>...]'
 SUBDIRECTORY_OK=Yes
 . git-sh-setup
+set_reflog_action "reset $*"
 
 update= reset_type=--mixed
 unset rev
@@ -81,7 +82,7 @@ then
 else
 	rm -f "$GIT_DIR/ORIG_HEAD"
 fi
-git-update-ref -m "reset $reset_type $*" HEAD "$rev"
+git-update-ref -m "$GIT_REFLOG_ACTION" HEAD "$rev"
 update_ref_status=$?
 
 case "$reset_type" in
-- 
1.4.4.3.gd2e4
Shawn O. Pearce· Dec 28, 2006, 07:34 UTC · lore

[PATCH 3/11] Use branch names in 'git-rebase -m' conflict hunks.

If a three-way merge in git-rebase generates a conflict then we should take advantage of git-merge-recursive's ability to include the branch name of each side of the conflict hunk by setting the GITHEAD_* environment variables.

In the case of rebase there aren't really two clear branches; we have the branch we are rebasing onto, and we have the branch we are currently rebasing. Since most conflicts will be arising between the user's current branch and the branch they are rebasing onto we assume the stuff that isn't in the current commit is the "onto" branch and the stuff in the current commit is the "current" branch.

This assumption may however come up wrong if the user resolves one conflict in such a way that it conflicts again on a future commit also being rebased. In this case the user's prior resolution will appear to be in the "onto" part of the hunk.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 git-rebase.sh |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)
Show changes to git-rebase.sh +10 −1
diff --git a/git-rebase.sh b/git-rebase.sh
index 5c7c4a6..828c59c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -81,10 +81,18 @@ continue_merge () {
 call_merge () {
 	cmt="$(cat $dotest/cmt.$1)"
 	echo "$cmt" > "$dotest/current"
-	git-merge-$strategy "$cmt^" -- HEAD "$cmt"
+	hd=$(git-rev-parse --verify HEAD)
+	cmt_name=$(git-symbolic-ref HEAD)
+	msgnum=$(cat $dotest/msgnum)
+	end=$(cat $dotest/end)
+	eval GITHEAD_$cmt='"${cmt_name##refs/heads/}~$(($end - $msgnum))"'
+	eval GITHEAD_$hd='"$(cat $dotest/onto_name)"'
+	export GITHEAD_$cmt GITHEAD_$hd
+	git-merge-$strategy "$cmt^" -- "$hd" "$cmt"
 	rv=$?
 	case "$rv" in
 	0)
+		unset GITHEAD_$cmt GITHEAD_$hd
 		return
 		;;
 	1)
@@ -314,6 +322,7 @@ fi
 
 mkdir -p "$dotest"
 echo "$onto" > "$dotest/onto"
+echo "$onto_name" > "$dotest/onto_name"
 prev_head=`git-rev-parse HEAD^0`
 echo "$prev_head" > "$dotest/prev_head"
 
-- 
1.4.4.3.gd2e4
Shawn O. Pearce· Dec 28, 2006, 07:35 UTC · lore

[PATCH 4/11] Ensure `git-pull` fails if `git-merge` fails.

If git-merge exits with a non-zero exit status so should git-pull. This way the caller of git-pull knows the task did not complete successfully simply by checking the process exit status.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 git-pull.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Show changes to git-pull.sh +1 −1
diff --git a/git-pull.sh b/git-pull.sh
index fd4ffb8..2725946 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -119,5 +119,5 @@ case "$strategy_args" in
 esac
 
 merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
-git-merge $no_summary $no_commit $squash $strategy_args \
+exec git-merge $no_summary $no_commit $squash $strategy_args \
 	"$merge_name" HEAD $merge_head
-- 
1.4.4.3.gd2e4
Shawn O. Pearce· Dec 28, 2006, 07:35 UTC · lore

[PATCH 5/11] Honor pull.{twohead,octopus} in git-merge.

If git-merge is invoked without a strategy argument it is probably being run as a porcelain-ish command directly and is not being run from within git-pull. However we still should honor whatever merge strategy the user may have selected in their configuration, just as `git-pull .` would have.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 git-merge.sh |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)
Show changes to git-merge.sh +14 −2
diff --git a/git-merge.sh b/git-merge.sh
index c7e033c..a8f673e 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -272,9 +272,21 @@ case "$use_strategies" in
 '')
 	case "$#" in
 	1)
-		use_strategies="$default_twohead_strategies" ;;
+		var="`git-repo-config --get pull.twohead`"
+		if test -n "$var"
+		then
+			use_strategies="$var"
+		else
+			use_strategies="$default_twohead_strategies"
+		fi ;;
 	*)
-		use_strategies="$default_octopus_strategies" ;;
+		var="`git-repo-config --get pull.octopus`"
+		if test -n "$var"
+		then
+			use_strategies="$var"
+		else
+			use_strategies="$default_octopus_strategies"
+		fi ;;
 	esac
 	;;
 esac
-- 
1.4.4.3.gd2e4
Shawn O. Pearce· Dec 28, 2006, 07:35 UTC · lore

[PATCH 6/11] Allow git-merge to select the default strategy.

Now that git-merge knows how to use the pull.{twohead,octopus} configuration options to select the default merge strategy there is no reason for git-pull to do the same immediately prior to invoking git-merge.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 git-pull.sh |   18 ------------------
 1 files changed, 0 insertions(+), 18 deletions(-)
Show changes to git-pull.sh +0 −18
diff --git a/git-pull.sh b/git-pull.sh
index 2725946..28d0819 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -90,18 +90,6 @@ case "$merge_head" in
 		echo >&2 "Cannot merge multiple branches into empty head"
 		exit 1
 	fi
-	var=`git-repo-config --get pull.octopus`
-	if test -n "$var"
-	then
-		strategy_default_args="-s $var"
-	fi
-	;;
-*)
-	var=`git-repo-config --get pull.twohead`
-	if test -n "$var"
-        then
-		strategy_default_args="-s $var"
-	fi
 	;;
 esac
 
@@ -112,12 +100,6 @@ then
 	exit
 fi
 
-case "$strategy_args" in
-'')
-	strategy_args=$strategy_default_args
-	;;
-esac
-
 merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
 exec git-merge $no_summary $no_commit $squash $strategy_args \
 	"$merge_name" HEAD $merge_head
-- 
1.4.4.3.gd2e4
Shawn O. Pearce· Dec 28, 2006, 07:35 UTC · lore

[PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.

Users who merge frequently from remote repositories tend to prefer `git-pull .` over `git-merge` for local merges, as the pull interface is then consistent with how the user performs merges from remote repositories.

Unfortunately `git-pull .` has a (small) amount of overhead on top of `git-merge` as it needs to first invoke git-fetch to prepare the FETCH_HEAD file. However we can easily detect this special case of a local merge and jump directly into git-merge, bypassing that overhead.

This change also allows users of `git-pull .` to take advantage of the change made in commit e0ec1819, where git-merge uses the local branch name in conflict hunks if it is invoked as a porcelain, rather than as a plumbing.

Users may also now use `git-pull . foo~3` to merge the early part of branch foo. This was not previously possible as git-fetch does not know how to fetch foo~3 from a repository.

Unfortunately we cannot use this git-fetch bypass if the user is also updating some sort of tracking branch in the local repository as part of the pull from the local repository. This however is a rather crazy usage of `git-pull .`, but we used to support it, so we issue a silly warning message and use the older-style git-fetch path to continue supporting it.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 git-pull.sh |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)
Show changes to git-pull.sh +27 −0
diff --git a/git-pull.sh b/git-pull.sh
index 28d0819..8c94fef 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -45,6 +45,33 @@ do
 	shift
 done
 
+if test "X$1" = X.
+then
+	# We are merging from this repository.  We can avoid fetch
+	# and go right into merge if the user isn't doing something
+	# odd like asking us to also update tracking branches in
+	# this repository as part of the pull.  Yeah, they probably
+	# shouldn't do that - but we allowed it in the past...
+	#
+	direct_merge=1
+	for remote
+	do
+		case "$remote" in
+		*:*) direct_merge=0; break;;
+		esac
+	done
+	if test $direct_merge = 1
+	then
+		shift
+		exec git-merge \
+			$no_summary $no_commit $squash $strategy_args \
+			"$@"
+	else
+		echo >&2 "Clever... Updating tracking branch while pulling from yourself."
+		echo >&2
+	fi
+fi
+
 orig_head=$(git-rev-parse --verify HEAD 2>/dev/null)
 git-fetch --update-head-ok "$@" || exit 1
 
-- 
1.4.4.3.gd2e4
Junio C Hamano· Dec 28, 2006, 08:08 UTC · re: Shawn O. Pearce · lore

Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.

"Shawn O. Pearce" <spearce@spearce.org> writes:
> Users may also now use `git-pull . foo~3` to merge the early part
> of branch foo.  This was not previously possible as git-fetch does
> not know how to fetch foo~3 from a repository.

I personally think this is not an improvement, but rather a new source of confusion. If the user wants a local merge, there is 'git-merge'. And the distinction between the commands makes it clear that local merge can merge any commits exactly because they are available locally, while remote fetch+merge needs to choose from what the remote side offers so not arbitrary commits like foo@{3.days.ago} cannot be pulled.

Also I thought there was a configuration variable that talks about "remote = ." (didn't I merge that patch -- I do not remember offhand) and I wonder how that interacts with this change.

How much performance gain are we talking about here?
Shawn Pearce· Dec 28, 2006, 08:17 UTC · re: Junio C Hamano · lore

Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.

Junio C Hamano <junkio@cox.net> wrote:
Show 13 quoted lines
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Users may also now use `git-pull . foo~3` to merge the early part
> > of branch foo.  This was not previously possible as git-fetch does
> > not know how to fetch foo~3 from a repository.
> 
> I personally think this is not an improvement, but rather a new
> source of confusion.  If the user wants a local merge, there is
> 'git-merge'.  And the distinction between the commands makes it
> clear that local merge can merge any commits exactly because
> they are available locally, while remote fetch+merge needs to
> choose from what the remote side offers so not arbitrary commits
> like foo@{3.days.ago} cannot be pulled.

True. But you know you are doing a local merge with `git pull .`. So why should you be restricted from using the capabilities of a local merge just because the frontend you prefer to use is limited when its doing remote merges?

I didn't really do this change for this feature, I did for the
performance (see below).
 
> Also I thought there was a configuration variable that talks
> about "remote = ."  (didn't I merge that patch -- I do not
> remember offhand) and I wonder how that interacts with this
> change.
I must have missed that discussion on the list.  Not sure how as
I read everything.  Oh, its that grey stuff upstairs not recalling
history as well as Git does... ;-)
 
> How much performance gain are we talking about here?
It halves my 'git pull . foo' times on my Mac OS X PowerPC 64 system:
  Without: ~900 ms
  With:    ~440 ms
-- 
Shawn.
Junio C Hamano· Dec 28, 2006, 09:35 UTC · re: Shawn Pearce · lore

Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.

Shawn Pearce <spearce@spearce.org> writes:
Show 12 quoted lines
>> I personally think this is not an improvement, but rather a new
>> source of confusion.  If the user wants a local merge, there is
>> 'git-merge'.  And the distinction between the commands makes it
>> clear that local merge can merge any commits exactly because
>> they are available locally, while remote fetch+merge needs to
>> choose from what the remote side offers so not arbitrary commits
>> like foo@{3.days.ago} cannot be pulled.
>
> True.  But you know you are doing a local merge with `git pull .`.
> So why should you be restricted from using the capabilities of a
> local merge just because the frontend you prefer to use is limited
> when its doing remote merges?

Personally I do not mind much about it because I happen to understand what "git pull" is doing.

But I do mind having to spend time defending why we special case only the dot form, when people with twisted minds start complaining about inconsistencies among "git pull .git", "git pull ." and "git pull $(pwd)". And no, I do not want to introduce likes of "test `cd .git && pwd` == `cd $1 && pwd`" in the code to make them behave consistently.

Shawn O. Pearce· Dec 28, 2006, 07:35 UTC · lore

[PATCH 8/11] Move better_branch_name above get_ref in merge-recursive.

To permit the get_ref function to use the static better_branch_name function to generate a string on demand I'm moving it up earlier. The actual logic was not affected in this change.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 merge-recursive.c |   24 ++++++++++++------------
 1 files changed, 12 insertions(+), 12 deletions(-)
Show changes to merge-recursive.c +12 −12
diff --git a/merge-recursive.c b/merge-recursive.c
index ca4f19e..1c84ed7 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1248,6 +1248,18 @@ static int merge(struct commit *h1,
 	return clean;
 }
 
+static const char *better_branch_name(const char *branch)
+{
+	static char githead_env[8 + 40 + 1];
+	char *name;
+
+	if (strlen(branch) != 40)
+		return branch;
+	sprintf(githead_env, "GITHEAD_%s", branch);
+	name = getenv(githead_env);
+	return name ? name : branch;
+}
+
 static struct commit *get_ref(const char *ref)
 {
 	unsigned char sha1[20];
@@ -1263,18 +1275,6 @@ static struct commit *get_ref(const char *ref)
 	return (struct commit *)object;
 }
 
-static const char *better_branch_name(const char *branch)
-{
-	static char githead_env[8 + 40 + 1];
-	char *name;
-
-	if (strlen(branch) != 40)
-		return branch;
-	sprintf(githead_env, "GITHEAD_%s", branch);
-	name = getenv(githead_env);
-	return name ? name : branch;
-}
-
 int main(int argc, char *argv[])
 {
 	static const char *bases[2];
-- 
1.4.4.3.gd2e4
Shawn O. Pearce· Dec 28, 2006, 07:35 UTC · lore

[PATCH 9/11] Allow merging bare trees in merge-recursive.

To support wider use cases, such as from within `git am -3`, the merge-recursive utility needs to accept not just commit-ish but also tree-ish as arguments on its command line.

If given a tree-ish then merge-recursive will create a virtual commit wrapping it, with the subject of the commit set to the best name we can derive for that tree, which is either the command line string (probably the SHA1), or whatever string appears in GITHEAD_*.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 merge-recursive.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
Show changes to merge-recursive.c +3 −0
diff --git a/merge-recursive.c b/merge-recursive.c
index 1c84ed7..bac16f5 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1268,6 +1268,9 @@ static struct commit *get_ref(const char *ref)
 	if (get_sha1(ref, sha1))
 		die("Could not resolve ref '%s'", ref);
 	object = deref_tag(parse_object(sha1), ref, strlen(ref));
+	if (object->type == OBJ_TREE)
+		return make_virtual_commit((struct tree*)object,
+			better_branch_name(ref));
 	if (object->type != OBJ_COMMIT)
 		return NULL;
 	if (parse_commit((struct commit *)object))
-- 
1.4.4.3.gd2e4
Junio C Hamano· Dec 28, 2006, 08:08 UTC · re: Shawn O. Pearce · lore

Re: [PATCH 9/11] Allow merging bare trees in merge-recursive.

"Shawn O. Pearce" <spearce@spearce.org> writes:
> To support wider use cases, such as from within `git am -3`, the
> merge-recursive utility needs to accept not just commit-ish but
> also tree-ish as arguments on its command line.

Yes, this was one of the things I did not like about merge-recursive (I think the original Python one may have accepted three trees but I am not sure --- it's so looong ago).

Shawn O. Pearce· Dec 28, 2006, 07:35 UTC · lore

[PATCH 10/11] Use merge-recursive in git-am -3.

By switching from merge-resolve to merge-recursive in the 3-way fallback behavior of git-am we gain a few benefits:

 * renames are automatically handled, like in rebase -m;
 * conflict hunks can reference the patch name;
 * its faster on Cygwin (less forks).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 git-am.sh |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)
Show changes to git-am.sh +5 −2
diff --git a/git-am.sh b/git-am.sh
index c3bbd78..7c0bb60 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -88,10 +88,12 @@ It does not apply to blobs recorded in its index."
     # This is not so wrong.  Depending on which base we picked,
     # orig_tree may be wildly different from ours, but his_tree
     # has the same set of wildly different changes in parts the
-    # patch did not touch, so resolve ends up canceling them,
+    # patch did not touch, so recursive ends up canceling them,
     # saying that we reverted all those changes.
 
-    git-merge-resolve $orig_tree -- HEAD $his_tree || {
+    eval GITHEAD_$his_tree='"$SUBJECT"'
+    export GITHEAD_$his_tree
+    git-merge-recursive $orig_tree -- HEAD $his_tree || {
 	    if test -d "$GIT_DIR/rr-cache"
 	    then
 		git-rerere
@@ -99,6 +101,7 @@ It does not apply to blobs recorded in its index."
 	    echo Failed to merge in the changes.
 	    exit 1
     }
+    unset GITHEAD_$his_tree
 }
 
 prec=4
-- 
1.4.4.3.gd2e4
Shawn O. Pearce· Dec 28, 2006, 07:35 UTC · lore

[PATCH 11/11] Improve merge performance by avoiding in-index merges.

In the early days of Git we performed a 3-way read-tree based merge before attempting any specific merge strategy, as our core merge strategies of merge-one-file and merge-recursive were slower script based programs which took far longer to execute. This was a good performance optimization in the past, as most merges were able to be handled strictly by `read-tree -m -u`.

However now that merge-recursive is a C based program which performs a full 3-way read-tree before it starts running we need to pay the cost of the 3-way read-tree twice if we have to do any sort of file level merging. This slows down some classes of simple merges which `read-tree -m -u` could not handle but which merge-recursive does automatically.

For a really trivial merge which can be handled entirely by `read-tree -m -u`, skipping the read-tree and just going directly into merge-recursive saves on average 50 ms on my PowerPC G4 system. May sound odd, but it does appear to be true.

In a really simple merge which needs to use merge-recursive to handle a file that was modified on both branches, skipping the read-tree in git-merge saves on average almost 100 ms (on the same PowerPC G4) as we avoid doing some work twice.

We only avoid `read-tree -m -u` if the only strategy to use is merge-recursive, as not all merge strategies perform as well as merge-recursive does.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 git-merge.sh |   39 ++++++++++++++++++++++-----------------
 1 files changed, 22 insertions(+), 17 deletions(-)
Show changes to git-merge.sh +22 −17
diff --git a/git-merge.sh b/git-merge.sh
index a8f673e..74d4fb0 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -341,23 +341,28 @@ f,*)
 ?,1,*,)
 	# We are not doing octopus, not fast forward, and have only
 	# one common.  See if it is really trivial.
-	git var GIT_COMMITTER_IDENT >/dev/null || exit
-
-	echo "Trying really trivial in-index merge..."
-	git-update-index --refresh 2>/dev/null
-	if git-read-tree --trivial -m -u -v $common $head "$1" &&
-	   result_tree=$(git-write-tree)
-	then
-	    echo "Wonderful."
-	    result_commit=$(
-	        echo "$merge_msg" |
-	        git-commit-tree $result_tree -p HEAD -p "$1"
-	    ) || exit
-	    finish "$result_commit" "In-index merge"
-	    dropsave
-	    exit 0
-	fi
-	echo "Nope."
+	case "$use_strategies" in
+	recursive|'recursive '|recur|'recur ')
+		: run merge later
+		;;
+	*)
+		git var GIT_COMMITTER_IDENT >/dev/null || exit
+		echo "Trying really trivial in-index merge..."
+		git-update-index --refresh 2>/dev/null
+		if git-read-tree --trivial -m -u -v $common $head "$1" &&
+		   result_tree=$(git-write-tree)
+		then
+			echo "Wonderful."
+			result_commit=$(
+				echo "$merge_msg" |
+				git-commit-tree $result_tree -p HEAD -p "$1"
+			) || exit
+			finish "$result_commit" "In-index merge"
+			dropsave
+			exit 0
+		fi
+		echo "Nope."
+	esac
 	;;
 *)
 	# An octopus.  If we can reach all the remote we are up to date.
-- 
1.4.4.3.gd2e4
Junio C Hamano· Dec 28, 2006, 08:08 UTC · re: Shawn O. Pearce · lore

Re: [PATCH 11/11] Improve merge performance by avoiding in-index merges.

"Shawn O. Pearce" <spearce@spearce.org> writes:
> For a really trivial merge which can be handled entirely by
> `read-tree -m -u`, skipping the read-tree and just going directly
> into merge-recursive saves on average 50 ms on my PowerPC G4 system.
> May sound odd, but it does appear to be true.

This sounds awfully attractive yet disruptive. Should be cooked in 'next' for at least two weeks, maybe even longer to verify that performance figure holds for everybody.

Also I think you need to make sure running merge-recursive upfront offers the same safety as the code you are removing then running it, as I vaguely recall its checking for local changes were slightly looser.

Shawn Pearce· Dec 28, 2006, 08:24 UTC · re: Junio C Hamano · lore

Re: [PATCH 11/11] Improve merge performance by avoiding in-index merges.

Junio C Hamano <junkio@cox.net> wrote:
Show 10 quoted lines
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > For a really trivial merge which can be handled entirely by
> > `read-tree -m -u`, skipping the read-tree and just going directly
> > into merge-recursive saves on average 50 ms on my PowerPC G4 system.
> > May sound odd, but it does appear to be true.
> 
> This sounds awfully attractive yet disruptive.  Should be cooked
> in 'next' for at least two weeks, maybe even longer to verify
> that performance figure holds for everybody.
I agree.  I have been thinking about doing this for a while but
just never sat down and did it until night.  To get it in 1.5.0 I
probably should have done this back in early Decmember.  Whoops,
bad timing on my part.  ;-)
 
> Also I think you need to make sure running merge-recursive
> upfront offers the same safety as the code you are removing then
> running it, as I vaguely recall its checking for local changes
> were slightly looser.
>From what I can tell, merge-recursive and read-tree -m are running

exactly the same code. So aside from the fact that I bypassed the update-index --refresh by accident, I don't think they will have different outcomes.

-- 
Shawn.
Johannes Schindelin· Dec 29, 2006, 17:44 UTC · re: Shawn Pearce · lore

Re: [PATCH 11/11] Improve merge performance by avoiding in-index merges.

Hi,
On Thu, 28 Dec 2006, Shawn Pearce wrote:
> From what I can tell, merge-recursive and read-tree -m are running
> exactly the same code.

That was the idea of tags/v1.4.3~333^2 "read-tree: move merge functions to the library" and v1.4.3~236^2~10 "merge-recur: use the unpack_trees() interface instead of exec()ing read-tree".

Ciao, Dscho

← back to recent threads