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

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

[Shawn O. Pearce]

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

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

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

[Shawn O. Pearce]

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

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

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

[Shawn O. Pearce]

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

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

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

[Shawn O. Pearce]

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

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

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

[Shawn O. Pearce]

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

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

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

[Shawn O. Pearce]

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

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

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

[Junio C Hamano]

"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?

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

[Shawn Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> "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.

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

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

>> 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.

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

[Shawn O. Pearce]

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

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

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

[Shawn O. Pearce]

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

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

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

[Junio C Hamano]

"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).

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

[Shawn O. Pearce]

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

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

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

[Shawn O. Pearce]

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

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

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

[Junio C Hamano]

"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.

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

[Shawn Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> "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.

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

[Johannes Schindelin]

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