From: Sverre Hvammen Johansen <hvammen@gmail.com>

Restructure git-merge.sh for preparation of new feature:

       Head reduction before selecting merge strategy

Some aspects of this patch does not make much sense without
the next patch in this series.

Signed-off-by: Sverre Hvammen Johansen <hvammen@gmail.com>
---
 git-merge.sh |  186 +++++++++++++++++++++++++++++++++-------------------------
 1 files changed, 105 insertions(+), 81 deletions(-)

diff --git a/git-merge.sh b/git-merge.sh
index 91fada7..fc14c4b 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -213,6 +213,47 @@ parse_config () {
 	args_left=$#
 }
 
+# Find reduced parents
+# The following variables are set as follow:
+#   reduced_parents: The reduced parents of those specified on the command line.
+#                    However, the actual parents are included if we never ff.
+#   common:          All common ancestors or not_queried
+#   ff_head:         Head or an reduced parent that may be a candidate for fast forward
+find_reduced_parents () {
+	if test $fast_forward = never
+	then
+		reduced_parents=$(git rev-parse "$@")
+		ff_head=$head
+		common=not_queried
+	else
+		if test $# = 1
+		then
+			common=$(git merge-base --all $head "$1")
+			if test "$common" = $head
+			then
+				reduced_parents=
+				ff_head=$1
+			elif test "$common" = "$1"
+			then
+				reduced_parents=
+				ff_head=$head
+			else
+				reduced_parents=$1
+				ff_head=$head
+
+			fi
+		else
+			reduced_parents=$(git show-branch --independent $head "$@")
+			# Here we may actually lie about which bransh is ff of head.
+			# This will preserve the order the user gave.
+			ff_head=${reduced_parents%%$LF*}
+			reduced_parents=${reduced_parents#$ff_head}
+			reduced_parents=${reduced_parents#$LF}
+			common=not_queried
+		fi
+	fi
+}
+
 test $# != 0 || usage
 
 have_message=
@@ -301,24 +342,28 @@ do
 done
 set x $remoteheads ; shift
 
+find_reduced_parents "$@"
+
+actual_parents=$(git rev-parse "$@")...
[ message continues ]

Hi,


As my student is pretty busy rewriting git-merge into a C builtin, can I 
ask to hold this patch off?

Thanks,
Dscho
--

Hi,


Just to keep you updated: Miklos has a version of builtin-merge which 
passes all but three test scripts (in total, there are only 6 test cases 
that do not pass).

Given that the restructuring of git-merge.sh affects only the octopus case 
(IIRC...), I think it is not asked too much to redo the change in the 
builtin-merge, which should be easier, too.

Ciao,
Dscho

--

From: Sverre Hvammen Johansen <hvammen@gmail.com>

This commit uses the reduced parents instead of the actual
parents specified for selecting the merge strategy when doing
a merge.  The recorded parents and the commit message stays
the same.

Some cases where we before needed an octopus strategy may now be
done using a two head strategy.

See the documentation for further details.

Signed-off-by: Sverre Hvammen Johansen <hvammen@gmail.com>
---
 Documentation/git-merge.txt |   20 +++++++++-------
 git-merge.sh                |   50 ++++++++++++++++++++++++-------------------
 2 files changed, 39 insertions(+), 31 deletions(-)

diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 9cf761d..845d0ed 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -36,7 +36,7 @@ include::merge-options.txt[]
 <remote>::
 	Other branch head merged into our branch.  You need at
 	least one <remote>.  Specifying more than one <remote>
-	obviously means you are trying an Octopus.
+	usually means you are trying an Octopus.
 
 
 include::fast-forward-options.txt[]
@@ -158,11 +158,12 @@ After seeing a conflict, you can do two things:
 JOINING MORE THAN TWO HISTORIES
 -------------------------------
 
-More than one remote may be specified on the command line.  Those
-remotes are used for selecting the merge startegy and is also used in
-the merge commit message.  However, some of these remotes may not be
-independent.  Only remotes with independent heads (reduced parents)
-will be recorded in the merge commit object.
+More than one remote may be specified on the command line.  Some of
+these remotes may not have independent heads.  Git will only use the
+remotes with independent heads (reduced parents) for selecting the
+merge startegy.  The reduced parents are the parents recorded in the
+merge commit object.  However, the commit message will reflect the
+remotes specified on the command line.
 
 The following sho...
[ message continues ]

From: Sverre Hvammen Johansen <hvammen@gmail.com>

This commit introduces fast forward option 'only'.  With --ff=only
merge succeeds only if it resolves to fast-forward merge.

This feature is useful for cases where a rebase is desired
instead of a real merge.  This option can then be used to
avoid an accidental merge.

See the documentation for further details.

Signed-off-by: Sverre Hvammen Johansen <hvammen@gmail.com>
---
 Documentation/fast-forward-options.txt |    9 ++
 git-merge.sh                           |   12 +-
 git-pull.sh                            |    2 +-
 t/t7601-merge-ff-options.sh            |  214 ++++++++++++++++++++++++++++++++
 4 files changed, 231 insertions(+), 6 deletions(-)

diff --git a/Documentation/fast-forward-options.txt b/Documentation/fast-forward-options.txt
index 9374aa9..41580ea 100644
--- a/Documentation/fast-forward-options.txt
+++ b/Documentation/fast-forward-options.txt
@@ -12,6 +12,10 @@ never::
 	Generate a merge commit even if the merge resolves as a
 	fast-forward.  This option is equivalent of '--no-ff'.
 
+only::
+	Only allow a fast-forward.  The merge will fail unless HEAD is
+	up to date or the merge resolves as a fast-forward.
+
 If your workflow is always to branch from the special branch
 ("master") when working on a topic and merge that back to "master", if
 you happen to have worked only on a single topic and the "master" was
@@ -42,3 +46,8 @@ The first merge of topicA or the only merge of topicB would have
 resulted in a fast forward without '--ff=never'.  Topic A consist of
 those commits that can be reached from master^2 without passing
 through any of the first-parent ancestries of master.
+
+However, if the workflow require that the branch you are merging with
+is based on the current HEAD you can use "only fast forward" policy to
+enforce fast forward or a failure.  The last merge of topicA in
+the example above would have failed with '--ff=only'.
diff --git a/git-merge.sh b/git-merge.sh
index 775d...
[ message continues ]