[PATCH] git-merge: do up-to-date check also for strategies ours, subtree.

[PATCH] git-merge: do up-to-date check also for strategies ours, subtree.

[Gerrit Pape]

If called with one argument, check also for no_trivial_merge_strategies
whether all the merge can already be reached by HEAD.  Otherwise git-merge
creates an unnecessary commit, e.g.:

 $ (git init && touch foo && git add foo && git commit -m foo) >/dev/null
 $ git merge -s ours master
 Merge made by ours.
 $ git log --pretty=oneline
 d941346f022b7cb70c51d8122de4ae82657ae943 Merge branch 'master'
 68a1d32229917d5d1f4c8f64096d1abde84e9f6b foo
 $

Signed-off-by: Gerrit Pape <pape@smarden.org>
---
 git-merge.sh |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/git-merge.sh b/git-merge.sh
index 5ccf282..e90f62a 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -287,9 +287,6 @@ esac
 echo "$head" >"$GIT_DIR/ORIG_HEAD"
 
 case "$index_merge,$#,$common,$no_commit" in
-f,*)
-	# We've been told not to try anything clever.  Skip to real merge.
-	;;
 ?,*,'',*)
 	# No common ancestors found. We need a real merge.
 	;;
@@ -299,6 +296,9 @@ f,*)
 	finish_up_to_date "Already up-to-date."
 	exit 0
 	;;
+f,*)
+	# We've been told not to try anything clever.  Skip to real merge.
+	;;
 ?,1,"$head",*)
 	# Again the most common case of merging one remote.
 	echo "Updating $(git rev-parse --short $head)..$(git rev-parse --short $1)"
-- 
debian.1.5.3_rc4.1-dirty

Re: [PATCH] git-merge: do up-to-date check also for strategies ours, subtree.

[Junio C Hamano]

Right now I do not have time to dig mailing list archive around
mid March 2006, and I do not recall the requestor's original
rationale, but I have a vague recollection that we added this
"no fast-forward check" specifically in response to a user
request.

Re: [PATCH] git-merge: do up-to-date check also for strategies ours, subtree.

[Jeff King]

On Thu, Aug 09, 2007 at 02:11:24PM -0700, Junio C Hamano wrote:

> Right now I do not have time to dig mailing list archive around
> mid March 2006, and I do not recall the requestor's original
> rationale, but I have a vague recollection that we added this
> "no fast-forward check" specifically in response to a user
> request.

Maybe it was the "I'm using a custom merge strategy that might refuse
the merge, but fast-forwards don't even invoke my merge strategy"
request?

-Peff

Re: [PATCH] git-merge: do up-to-date check also for strategies ours, subtree.

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Right now I do not have time to dig mailing list archive around
> mid March 2006, and I do not recall the requestor's original
> rationale, but I have a vague recollection that we added this
> "no fast-forward check" specifically in response to a user
> request.

I do not think of a valid reason not to apply your patch.  We
wanted to avoid the trivial-merge codepath, but that is not a
valid reason to record a fast forward situation as a merge of
any kind.

Re: [PATCH] git-merge: do up-to-date check also for strategies ours, subtree.

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Right now I do not have time to dig mailing list archive around
>> mid March 2006, and I do not recall the requestor's original
>> rationale, but I have a vague recollection that we added this
>> "no fast-forward check" specifically in response to a user
>> request.
>
> I do not think of a valid reason not to apply your patch.  We
> wanted to avoid the trivial-merge codepath, but that is not a
> valid reason to record a fast forward situation as a merge of
> any kind.

Gaah.  I take it back.  At least, subtree _MUST_ not honor
fast-forward blindly.  git-gui.git project is merged into
git.git with that strategy, but if I pull from Shawn once, and
then he has more updates while I do not have anything on my
tree, it will be a fast-forward.  I should not be setting the
git.git tree to that of git-gui.git in such a case.

Re: [PATCH] git-merge: do up-to-date check also for strategies ours, subtree.

[Gerrit Pape]

On Thu, Aug 09, 2007 at 02:11:24PM -0700, Junio C Hamano wrote:
> Right now I do not have time to dig mailing list archive around
> mid March 2006, and I do not recall the requestor's original
> rationale, but I have a vague recollection that we added this
> "no fast-forward check" specifically in response to a user
> request.

Hmm, I don't think my patch affects fast-forwards at all, it checks for
no_trivial_merge_strategies whether the remote, that should be merged,
has any commits that are not in the current head.  If not, no merge
strategy should have to do anything.

The patch moves the first case switch at the third position.  If, with
the patch, the first switch matches, it doesn't change behavior as it
does the same as the third; if the second switch matches, git-merge will
report 'Already up-to-date.' and exit.

This is with the patch:

 $ (git init && touch foo && git add foo && git commit -m foo) >/dev/null
 $ git checkout -b b
 Switched to a new branch "b"
 $ (touch bar && git add bar && git commit -m bar) >/dev/null
 $ git checkout master
 Switched to branch "master"
 $ git merge b
 Updating 769e777..8a03d99
 Fast forward
  0 files changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 bar
 $ git reset --hard HEAD^
 HEAD is now at 769e777... foo
 $ git merge -s ours b
 Merge made by ours.
 $ git show
 commit f0dc487c15e502bc7ee823b6907468eb78668dbb
 Author: Gerrit Pape <pape@smarden.org>
 Date:   Fri Aug 10 13:44:10 2007 +0000
 
     Merge branch 'b'
 
 diff --git a/bar b/bar
 deleted file mode 100644
 index e69de29..0000000
 $ git merge -s ours b
 Already up-to-date.
 $ 

Without the patch, the last command results in

 $ git merge -s ours b
 Merge made by ours.
 $ git show
 commit 21154261ff23f64fc38e8a2ae79c7a1cccaeacd4
 Author: Gerrit Pape <pape@smarden.org>
 Date:   Fri Aug 10 13:48:54 2007 +0000
 
     Merge branch 'b'
 $ 

Regards, Gerrit.

[PATCH] git-merge: do up-to-date check also for all strategies

[Junio C Hamano]

How about doing this instead?  When "subtree" is used for
criss-cross (which is not recommended), you should not allow
fast-forward.  Also "ours" should not allow fast-forward, as the
result will be their tree and by definition that is not what
"ours" want.  All strategies including "ours" and "subtree"
should allow up-to-date (i.e. we are ahead of them).

Looking at git-merge again after a long while makes me wonder 
if it makes sense to support only a single strategy.  Back when
we did not know which one of recursive or multi-head resolve was
the right way to go, being able to try multiple strategies and
pick the "best" result sounded like a fun plan, but I do not
think anybody uses this capability.

-- >8 --
[PATCH] git-merge: do up-to-date check also for all strategies

This clarifies the logic to omit fast-forward check and omit
trivial merge before running the specified strategy.

The "index_merge" variable started out as a flag to say "do not
do anything clever", but when recursive was changed to skip the
trivial merge, the semantics were changed and the variable alone
does not make sense anymore.

This splits the variable into two, allow_fast_forward (which is
almost always true, and avoids making a merge commit when the
other commit is a descendant of our branch, but is set to false
for ours and subtree) and allow_trivial_merge (which is false
for ours, recursive and subtree).

Unlike the earlier implementation, the "ours" strategy allows an
up-to-date condition.  When we are up-to-date, the result will
be our commit, and by definition, we will have our tree as the
result.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 git-merge.sh                |   35 +++++++++++--------
 t/t6028-merge-up-to-date.sh |   77 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 97 insertions(+), 15 deletions(-)
 create mode 100755 t/t6028-merge-up-to-date.sh

diff --git a/git-merge.sh b/git-merge.sh
index 5ccf282..3a01db0 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -19,10 +19,12 @@ LF='
 all_strategies='recur recursive octopus resolve stupid ours subtree'
 default_twohead_strategies='recursive'
 default_octopus_strategies='octopus'
-no_trivial_merge_strategies='ours subtree'
+no_fast_forward_strategies='subtree ours'
+no_trivial_strategies='recursive recur subtree ours'
 use_strategies=
 
-index_merge=t
+allow_fast_forward=t
+allow_trivial_merge=t
 
 dropsave() {
 	rm -f -- "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/MERGE_MSG" \
@@ -265,11 +267,20 @@ esac
 
 for s in $use_strategies
 do
-	for nt in $no_trivial_merge_strategies
+	for ss in $no_fast_forward_strategies
 	do
 		case " $s " in
-		*" $nt "*)
-			index_merge=f
+		*" $ss "*)
+			allow_fast_forward=f
+			break
+			;;
+		esac
+	done
+	for ss in $no_trivial_strategies
+	do
+		case " $s " in
+		*" $ss "*)
+			allow_trivial_merge=f
 			break
 			;;
 		esac
@@ -286,10 +297,7 @@ case "$#" in
 esac
 echo "$head" >"$GIT_DIR/ORIG_HEAD"
 
-case "$index_merge,$#,$common,$no_commit" in
-f,*)
-	# We've been told not to try anything clever.  Skip to real merge.
-	;;
+case "$allow_fast_forward,$#,$common,$no_commit" in
 ?,*,'',*)
 	# No common ancestors found. We need a real merge.
 	;;
@@ -299,7 +307,7 @@ f,*)
 	finish_up_to_date "Already up-to-date."
 	exit 0
 	;;
-?,1,"$head",*)
+t,1,"$head",*)
 	# Again the most common case of merging one remote.
 	echo "Updating $(git rev-parse --short $head)..$(git rev-parse --short $1)"
 	git update-index --refresh 2>/dev/null
@@ -322,11 +330,8 @@ f,*)
 	# We are not doing octopus, not fast forward, and have only
 	# one common.
 	git update-index --refresh 2>/dev/null
-	case " $use_strategies " in
-	*' recursive '*|*' recur '*)
-		: run merge later
-		;;
-	*)
+	case "$allow_trivial_merge" in
+	t)
 		# See if it is really trivial.
 		git var GIT_COMMITTER_IDENT >/dev/null || exit
 		echo "Trying really trivial in-index merge..."
diff --git a/t/t6028-merge-up-to-date.sh b/t/t6028-merge-up-to-date.sh
new file mode 100755
index 0000000..f8f3e3f
--- /dev/null
+++ b/t/t6028-merge-up-to-date.sh
@@ -0,0 +1,77 @@
+#!/bin/sh
+
+test_description='merge fast forward and up to date'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+	>file &&
+	git add file &&
+	test_tick &&
+	git commit -m initial &&
+	git tag c0 &&
+
+	echo second >file &&
+	git add file &&
+	test_tick &&
+	git commit -m second &&
+	git tag c1 &&
+	git branch test
+'
+
+test_expect_success 'merge -s recursive up-to-date' '
+
+	git reset --hard c1 &&
+	test_tick &&
+	git merge -s recursive c0 &&
+	expect=$(git rev-parse c1) &&
+	current=$(git rev-parse HEAD) &&
+	test "$expect" = "$current"
+
+'
+
+test_expect_success 'merge -s recursive fast-forward' '
+
+	git reset --hard c0 &&
+	test_tick &&
+	git merge -s recursive c1 &&
+	expect=$(git rev-parse c1) &&
+	current=$(git rev-parse HEAD) &&
+	test "$expect" = "$current"
+
+'
+
+test_expect_success 'merge -s ours up-to-date' '
+
+	git reset --hard c1 &&
+	test_tick &&
+	git merge -s ours c0 &&
+	expect=$(git rev-parse c1) &&
+	current=$(git rev-parse HEAD) &&
+	test "$expect" = "$current"
+
+'
+
+test_expect_success 'merge -s ours fast-forward' '
+
+	git reset --hard c0 &&
+	test_tick &&
+	git merge -s ours c1 &&
+	expect=$(git rev-parse c0^{tree}) &&
+	current=$(git rev-parse HEAD^{tree}) &&
+	test "$expect" = "$current"
+
+'
+
+test_expect_success 'merge -s subtree up-to-date' '
+
+	git reset --hard c1 &&
+	test_tick &&
+	git merge -s subtree c0 &&
+	expect=$(git rev-parse c1) &&
+	current=$(git rev-parse HEAD) &&
+	test "$expect" = "$current"
+
+'
+
+test_done