[PATCH] provide a new "theirs" strategy, useful for rebase --onto

[PATCH] provide a new "theirs" strategy, useful for rebase --onto

[Paolo Bonzini]

The new strategy resolves only two heads, and the result of the merge
is always the second head.  It can be useful with `rebase --onto`,
because it always resolves conflicts in favor of the commits
being applied.

The patch includes an update to git-rebase's documentation, showing
how to use the new patch to convert an "--amend"ing commit into a
separate one, as if --amend had not been used.
---
 .gitignore                         |    1 +
 Documentation/git-rebase.txt       |   39 +++++++++++++++++++++++++
 Documentation/merge-strategies.txt |    6 ++++
 Makefile                           |    3 +-
 builtin-merge-theirs.c             |   56 ++++++++++++++++++++++++++++++++++++
 builtin.h                          |    1 +
 git-merge.sh                       |    6 ++--
 git.c                              |    1 +
 t/t3409-rebase-merge-theirs.sh     |   43 +++++++++++++++++++++++++++
 9 files changed, 152 insertions(+), 4 deletions(-)
 create mode 100644 builtin-merge-theirs.c
 create mode 100755 t/t3409-rebase-merge-theirs.sh

	This is equivalent to this script that I suggested in
	http://permalink.gmane.org/gmane.comp.version-control.git/83528

		#! /bin/sh
		eval git reset \$$# -- .
		git-checkout-index -q -f -a 

	The use-case in the manual is also based on that thread.

diff --git a/.gitignore b/.gitignore
index 4ff2fec..6d000e5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -77,6 +77,7 @@ git-merge-recursive
 git-merge-resolve
 git-merge-stupid
 git-merge-subtree
+git-merge-theirs
 git-mergetool
 git-mktag
 git-mktree
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index cc4e94f..577ae83 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -168,6 +168,45 @@ This is useful if F and G were flawed in some way, or should not be
 part of topicA.  Note that the argument to --onto and the <upstream>
 parameter can be any valid commit-ish.
 
+`git rebase` rewrites history, and this is in general something that
+you do not want to do when somebody else is pulling from your
+repository.  For this reason, history rewrites ("forced updates")
+are often forbidden when pushing to a remote repository.  However,
+there are other commands that rewrite history, and indeed rebasing
+can help fixing mistakes and reverting to the published history.
+
+For example, `git commit --amend` also has this effect, and it can
+happen that you use it even though you had already pushed to the
+remote repository before amending your commit.  You can then
+use `git rebase` (with the --onto option) to transform the `--amend`
+commit into a separate commit (as if you had not used the `--amend`
+option).  The situation is like this:
+
+------------
+    o---D---E  origin/master
+         \
+          E'---F---G---H---I  master
+------------
+
+because the parent of the amended commit E' is D, that is
+origin/master^.  To avoid a forced update from master to
+origin/master, you need the history to look like this:
+
+------------
+    o---D---E  origin/master
+             \
+              E''---F'---G'---H'---I'  master
+------------
+
+You can achieve this with:
+
+    git-rebase -s theirs --onto origin/master origin/master^ master
+
+The merge strategy `-s theirs` resolves conflicts in favor of the commits
+being rebased---in this case, you know that the only conflicts will occur
+when replaying E', and you definitely E'' to have those changes.
+
+
 In case of conflict, git-rebase will stop at the first problematic commit
 and leave conflict markers in the tree.  You can use git diff to locate
 the markers (<<<<<<) and make edits to resolve the conflict.  For each
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 1276f85..384c34a 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -34,6 +34,12 @@ ours::
 	be used to supersede old development history of side
 	branches.
 
+theirs::
+	This resolves only two heads, and the result of the merge is
+	always the second head.  It can be useful with `rebase --onto`,
+	because it always resolves conflicts in favor of the commits
+	being applied.
+
 subtree::
 	This is a modified recursive strategy. When merging trees A and
 	B, if B corresponds to a subtree of A, B is first adjusted to
diff --git a/Makefile b/Makefile
index cce5a6e..6241e5d 100644
--- a/Makefile
+++ b/Makefile
@@ -515,6 +515,7 @@ BUILTIN_OBJS += builtin-merge-base.o
 BUILTIN_OBJS += builtin-merge-file.o
 BUILTIN_OBJS += builtin-merge-ours.o
 BUILTIN_OBJS += builtin-merge-recursive.o
+BUILTIN_OBJS += builtin-merge-theirs.o
 BUILTIN_OBJS += builtin-mv.o
 BUILTIN_OBJS += builtin-name-rev.o
 BUILTIN_OBJS += builtin-pack-objects.o
@@ -1343,7 +1344,7 @@ check-docs::
 		case "$$v" in \
 		git-merge-octopus | git-merge-ours | git-merge-recursive | \
 		git-merge-resolve | git-merge-stupid | git-merge-subtree | \
-		git-fsck-objects | git-init-db | \
+		git-merge-theirs | git-fsck-objects | git-init-db | \
 		git-?*--?* ) continue ;; \
 		esac ; \
 		test -f "Documentation/$$v.txt" || \
diff --git a/builtin-merge-theirs.c b/builtin-merge-theirs.c
new file mode 100644
index 0000000..6f3e66a
--- /dev/null
+++ b/builtin-merge-theirs.c
@@ -0,0 +1,56 @@
+/*
+ * Implementation the `theirs' merge strategy.
+ *
+ * Copyright (c) 2008 Paolo Bonzini
+ *
+ * A one-way merge, declaring that the merged-from tree trumps everybody else.
+ */
+
+#include "cache.h"
+#include "run-command.h"
+#include "tree.h"
+#include "tree-walk.h"
+#include "unpack-trees.h"
+
+int cmd_merge_theirs(int argc, const char **argv, const char *prefix)
+{
+	int i, fd;
+	struct tree *tree;
+	struct tree_desc desc;
+	struct unpack_trees_options opts;
+	struct lock_file lock_file;
+	unsigned char sha1[20];
+
+	if (argc < 4)
+		die("Usage: %s <base>... -- <head> <remote> ...\n", argv[0]);
+
+	for (i = 1; i < argc; ++i)
+		if (!strcmp(argv[i], "--"))
+			break;
+	if (argc - i != 3) /* "--" "<head>" "<remote>" */
+		die("Not handling anything other than two heads merge.");
+	if (get_sha1(argv[i + 2], sha1))
+		die("%s: not a valid SHA1", argv[i + 2]);
+	if (unmerged_cache())
+		die("you need to resolve your current index first");
+
+	fd = hold_locked_index(&lock_file, 1);
+
+	memset(&opts, 0, sizeof(opts));
+	opts.update = 1;
+	opts.reset = 1;
+	opts.merge = 1;
+	opts.fn = oneway_merge;
+	opts.src_index = &the_index;
+	opts.dst_index = &the_index;
+
+	tree = parse_tree_indirect(sha1);
+	init_tree_desc(&desc, tree->buffer, tree->size);
+	if (unpack_trees(1, &desc, &opts))
+		return 128;
+
+	if (write_cache(fd, active_cache, active_nr) ||
+	    commit_locked_index(&lock_file))
+		die("unable to write new index file");
+	return 0;
+}
diff --git a/builtin.h b/builtin.h
index 8bda111..933ba84 100644
--- a/builtin.h
+++ b/builtin.h
@@ -60,6 +60,7 @@ extern int cmd_merge_base(int argc, const char **argv, const char *prefix);
 extern int cmd_merge_ours(int argc, const char **argv, const char *prefix);
 extern int cmd_merge_file(int argc, const char **argv, const char *prefix);
 extern int cmd_merge_recursive(int argc, const char **argv, const char *prefix);
+extern int cmd_merge_theirs(int argc, const char **argv, const char *prefix);
 extern int cmd_mv(int argc, const char **argv, const char *prefix);
 extern int cmd_name_rev(int argc, const char **argv, const char *prefix);
 extern int cmd_pack_objects(int argc, const char **argv, const char *prefix);
diff --git a/git-merge.sh b/git-merge.sh
index 2d177c1..24ba651 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -30,11 +30,11 @@ test -z "$(git ls-files -u)" ||
 LF='
 '
 
-all_strategies='recur recursive octopus resolve stupid ours subtree'
+all_strategies='recur recursive octopus resolve stupid ours theirs subtree'
 default_twohead_strategies='recursive'
 default_octopus_strategies='octopus'
-no_fast_forward_strategies='subtree ours'
-no_trivial_strategies='recursive recur subtree ours'
+no_fast_forward_strategies='subtree ours theirs'
+no_trivial_strategies='recursive recur subtree ours theirs'
 use_strategies=
 
 allow_fast_forward=t
diff --git a/git.c b/git.c
index 272bf03..4ee0822 100644
--- a/git.c
+++ b/git.c
@@ -326,6 +326,7 @@ static void handle_internal_command(int argc, const char **argv)
 		{ "merge-ours", cmd_merge_ours, RUN_SETUP },
 		{ "merge-recursive", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE },
 		{ "merge-subtree", cmd_merge_recursive, RUN_SETUP | NEED_WORK_TREE },
+		{ "merge-theirs", cmd_merge_theirs, RUN_SETUP },
 		{ "mv", cmd_mv, RUN_SETUP | NEED_WORK_TREE },
 		{ "name-rev", cmd_name_rev, RUN_SETUP },
 		{ "pack-objects", cmd_pack_objects, RUN_SETUP },
diff --git a/t/t3409-rebase-merge-theirs.sh b/t/t3409-rebase-merge-theirs.sh
new file mode 100755
index 0000000..01a0434
--- /dev/null
+++ b/t/t3409-rebase-merge-theirs.sh
@@ -0,0 +1,43 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Paolo Bonzini
+#
+
+test_description='git rebase -s theirs test'
+
+. ./test-lib.sh
+
+test_expect_success setup  '
+	T="A quick brown fox jumps over the lazy dog."
+	echo "$T" >file &&
+	echo "$T" >untouched
+	git add file untouched &&
+	git commit -m"initial" &&
+	for i in 1 2 3 4 5
+	do
+		echo "$i $T"
+	done >file &&
+	git commit -a -m"more work" &&
+	git branch origin &&
+	sed "s/5/AMEND/" file >file.tmp &&
+	mv file.tmp file &&
+	git commit --amend -a -m"master amended." &&
+	for i in 6 7 8 9 10
+	do
+		echo "$i $T" >> file &&
+		git commit -a -m"$i" || exit 1
+	done &&
+	git branch amended
+'
+
+test_expect_success 'grafting amended history using rebase -s theirs...' '
+	git rebase -s theirs --onto origin origin^ master &&
+	git diff amended HEAD'
+
+test_expect_success '... should allow a subsequent fast forward merge' '
+	git checkout origin &&
+	git merge master &&
+	test $(git rev-parse origin) = $(git rev-parse master)
+'
+
+test_done
-- 
1.5.5

Re: [PATCH] provide a new "theirs" strategy, useful for rebase --onto

[Peter Karlsson]

Paolo Bonzini:

I found a typo in the documentation:

> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
[...]
> +The merge strategy `-s theirs` resolves conflicts in favor of the commits
> +being rebased---in this case, you know that the only conflicts will occur
> +when replaying E', and you definitely E'' to have those changes.

It should say "...you definitely *want* E'' to have..."

-- 
\\// Peter - http://www.softwolves.pp.se/

Re: [PATCH] provide a new "theirs" strategy, useful for rebase --onto

[Paolo Bonzini]

Paolo Bonzini wrote:
> The new strategy resolves only two heads, and the result of the merge
> is always the second head.  It can be useful with `rebase --onto`,
> because it always resolves conflicts in favor of the commits
> being applied.
> 
> The patch includes an update to git-rebase's documentation, showing
> how to use the new patch to convert an "--amend"ing commit into a
> separate one, as if --amend had not been used.

Signed-Off-By: Paolo Bonzini  <bonzini@gnu.org>

(i.e. forge it in my original commit message if the patch is accepted).

Paolo

Re: [PATCH] provide a new "theirs" strategy, useful for rebase --onto

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

On Fri, Jun 06, 2008 at 12:59:30PM +0200, Paolo Bonzini <bonzini@gnu.org> wrote:
> The new strategy resolves only two heads, and the result of the merge
> is always the second head.  It can be useful with `rebase --onto`,
> because it always resolves conflicts in favor of the commits
> being applied.

Just wanted to say I like the idea. :-)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] provide a new "theirs" strategy, useful for rebase --onto

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

> +For example, `git commit --amend` also has this effect, and it can
> +happen that you use it even though you had already pushed to the
> +remote repository before amending your commit.  You can then
> +use `git rebase` (with the --onto option) to transform the `--amend`
> +commit into a separate commit (as if you had not used the `--amend`
> +option).  The situation is like this:
> +
> +------------
> +    o---D---E  origin/master
> +         \
> +          E'---F---G---H---I  master
> +------------
> +
> +because the parent of the amended commit E' is D, that is
> +origin/master^.  To avoid a forced update from master to
> +origin/master, you need the history to look like this:
> +
> +------------
> +    o---D---E  origin/master
> +             \
> +              E''---F'---G'---H'---I'  master
> +------------
> +
> +You can achieve this with:
> +
> +    git-rebase -s theirs --onto origin/master origin/master^ master
> +
> +The merge strategy `-s theirs` resolves conflicts in favor of the commits
> +being rebased---in this case, you know that the only conflicts will occur
> +when replaying E', and you definitely E'' to have those changes.

Isn't this a very risky thing to suggest as if it is a generally
applicable solution?  What happens if others have already worked on top of
E and your history looked like this?

    o---D---E---X---Y  origin/master
         \
          E'---F---G---H---I  master

The reader would want this history:


    o---D---E---X---Y  origin/master
                     \
                      E''--F'--G'--H'--I'  master

where difference between Y and E'' contains the change between E and E'.

However, neither "rebase -s theirs --onto Y D master" (use of D is more in
the spirit of your original example than literal origin/master^) nor
"rebase -s theirs --onto Y origin/master^ master" (which is nonsense but
careless readers would be tempted to "adjust" your example to their
situation) would give such a tree.  E'' should not have the same tree as
E' in this case.

I think I know why you wanted to do it in the original context without X
and Y.  Use of "-s theirs" would allow you to record the tree of E'
without conflicts.  But even that I do not agree is a good thing to do.

Because original E' was an amend of E, its log message explained
everything E did and more.  You cannot leave that same commit message in
E''.  What you did in E was already explained in the history, so now you
would want to talk about the incremental change on top of it when you
desribe E''.  For that, replaying of E' must stop to allow you to fix up
the log message.  It shouldn't silently go on.

Yes, you may want an easy way to say "the result should have the same tree
as E'" while replaying of E' on top of E _when_ you have to resolve the
conflict.  But that is a separate issue ("git checkout $other_head --
$conflicted_paths", or somesuch).  Using this in rebase is a horrible
example inviting misuse and a broken history, I think.

Re: [PATCH] provide a new "theirs" strategy, useful for rebase --onto

[Paolo Bonzini]

> Because original E' was an amend of E, its log message explained
> everything E did and more.  You cannot leave that same commit message in
> E''.  What you did in E was already explained in the history, so now you
> would want to talk about the incremental change on top of it when you
> desribe E''.  For that, replaying of E' must stop to allow you to fix up
> the log message. 

Yes, I had suggested in the original thread to follow up with a "git 
rebase -i" to fix the commit message, because "git-rebase--interactive 
--help" did not show a -s option.  However, I found out that it does 
support it, so it is probably better to use "git rebase -i -s theirs 
--onto ..." directly.

> Yes, you may want an easy way to say "the result should have the same tree
> as E'" while replaying of E' on top of E _when_ you have to resolve the
> conflict.  But that is a separate issue ("git checkout $other_head --
> $conflicted_paths", or somesuch).  Using this in rebase is a horrible
> example inviting misuse and a broken history, I think.

You mean that I should a) drop the example from git-rebase.1, b) reword 
it to clarify it, c) drop the patch completely?

Paolo

Re: [PATCH] provide a new "theirs" strategy, useful for rebase --onto

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

>> Because original E' was an amend of E, its log message explained
>> everything E did and more.  You cannot leave that same commit message in
>> E''.  What you did in E was already explained in the history, so now you
>> would want to talk about the incremental change on top of it when you
>> desribe E''.  For that, replaying of E' must stop to allow you to fix up
>> the log message.
>
> Yes, I had suggested in the original thread to follow up with a "git
> rebase -i" to fix the commit message, because "git-rebase--interactive
> --help" did not show a -s option.  However, I found out that it does
> support it, so it is probably better to use "git rebase -i -s theirs
> --onto ..." directly.

Yeah, but that is only about the commit log message.  The issue of
recording a wrong tree when commits X and Y exist is not alleviated, is
it?

> You mean that I should a) drop the example from git-rebase.1, b)
> reword it to clarify it, c) drop the patch completely?

I have to say that the rebase example is too misleading --- unless it is
accompanied by a lot of disclaimers, its risk to give broken result to
people probably is worse than the benefit. I am afraid that we would need
a lot better use case to justify the use of "theirs" than what you wrote.

I have occasionally seen valid situations to use "ours", but I personally
haven't been in a situation that merge using "theirs" is a good solution.
Obviously if you start from a wrong branch, you should be in the situation
that you would want to merge using "theirs", just like when you started
from the right branch and would use "ours", but in practice that never
happened to me as far as I can recall.  I am not sure where this asymmetry
comes from.

On the other hand, I've sometimes heard people say "when I get a merge
conflict, I'd want to discard what I did _only in the conflicted part_."
I am not sure if such a conflict resolution makes much sense in practice,
but perhaps people know that their changes are worthless crap anyway, and
do not even care about their work themselves, to the point that they would
rather discard what they did than spend more time to fix them up properly.
Whether that makes sense or not, what they want is different from "theirs"
(which is opposite of "ours"); they want to keep their own changes for
parts that did not conflict, and give up what they did only in the
conflicted part.  Perhaps such a kind of mixed conflict resolution should
be supported under the name of "theirs", even though that would make
"ours" and "theirs" _not_ the opposite of each other.  I dunno...

Re: [PATCH] provide a new "theirs" strategy, useful for rebase --onto

[Paolo Bonzini]

> Yeah, but that is only about the commit log message.  The issue of
> recording a wrong tree when commits X and Y exist is not alleviated, is
> it?

No, it's not.

> On the other hand, I've sometimes heard people say "when I get a merge
> conflict, I'd want to discard what I did _only in the conflicted part_."
> I am not sure if such a conflict resolution makes much sense in practice,
> but perhaps people know that their changes are worthless crap anyway, and
> do not even care about their work themselves, to the point that they would
> rather discard what they did than spend more time to fix them up properly.
> Whether that makes sense or not, what they want is different from "theirs"
> (which is opposite of "ours"); they want to keep their own changes for
> parts that did not conflict, and give up what they did only in the
> conflicted part.  Perhaps such a kind of mixed conflict resolution should
> be supported under the name of "theirs", even though that would make
> "ours" and "theirs" _not_ the opposite of each other.  I dunno...

Hmm, anyway you do want to test what this strategy would do --- before 
merging.  The point of "ours"/"theirs" is AFAICS that they *cannot* 
produce broken trees (they can cause you to lose committed stuff if used 
carelessly, but the resulting tree is already in some branch and 
supposedly has already been tested).  So breaking the symmetry would not 
be good probably.

I guess I see the reason why "ours" is more useful than "theirs".  The 
reason is that rebase (and "rebase -i" in particular is in some sense 
different from most other git operations.  Git workflows are 
merge-based, so your checked-out branch is the one where the interesting 
stuff is happening; if you wanted a "theirs" merge, you would probably 
do it as a "ours" merge in the other branch.  Rebase instead is 
cherrypicking basically, so "ours" makes no sense (it would just *not* 
cherrypick).

(It also explains why I saw a use case for "theirs" -- as a former arch 
user, I still tend to think in terms of cherrypicks more than merges).

The correct way to proceed would be something like "git rebase -i --onto 
origin/master $(git merge-base origin/master master) master", and then 
if you have

    A--B--C--X--Y     origin/master
        \
         --C'--D--E      master

change

    pick C'
    pick D
    pick E

into

    reset C'^
    pick --strategy=theirs C'
    mark :1
    reset origin/master
    pick :1
    pick D
    pick E

Then I guess the correct way to go is to write a custom script that uses 
the sequencer to make the rebase scenario less dangerous.  You can do

    #! /bin/sh
    # git-merge-after-amend <branch>
    #
    # Makes it possible to do a fast-forward merge of <branch>
    # into HEAD, assuming that the first diverging commit of <branch>
    # is an --amend'ed version of the first diverging commit of HEAD.
    us=$(git rev-parse HEAD)
    them=$(git rev-parse $1)
    base=$(git merge-base $us $them)

    (echo reset $base
    first=t
    git rev-list --reverse $us..$them | while read i do
      if test "$first" = t; then
        first=
        echo pick --strategy=theirs $i
        echo mark :1
        echo reset $us
        echo pick --edit :1
      else
        echo pick $i
      fi
    done) | git-sequencer

This script could actually become a merge strategy, so that you could do

    git reset --hard origin/master
    git merge -s split-first HEAD@{1}

This is maybe a little contrived (what if there are conflits, ecc.), but 
I like how it shows git's pluggability.

So, as a result of the discussion, I think that:

1) it can be useful to put the "theirs" strategy into git, especially as 
the sequencer (which is cherrypick-based) becomes an important component 
of some git porcelain; I would remove the rebase example from my patch 
and make it just a power-user option (same as "-s ours").

2) user-defined merge strategies can be useful.  So it would make sense 
to modify "git-merge" so that it accepts arbitrary merge strategies 
instead of just the predefined ones.  These would default to disallowing 
fast forward and trivial merges.  (Possibly, as a safety net, "index", 
"base", "file", "one-file", "tree" should be excluded... this in turn 
means adding an interface to the commands array in git.c... again, I can 
do this -- if it is considered interesting; I'd like to know that in 
advance -- after the built-in merge is committed).

3) this scenario giveit would make sense to provide the strategy option 
to "git cherry-pick".  I can write a patch for "git cherry-pick" if you 
are interested, though I'd like to have a hint about what to do with the 
short option "-s", which is already taken by "--signoff".  The same 
thing could be done to the sequencer's pick command, so I'm also CCing 
Stephan Beyer about this.

4) A useful option for the sequencer (and possibly for git-rebase) would 
be "--batch", ensuring that a single execution of the sequencer does the 
entire job.  "--edit" would then be changed to mean "ask user to edit 
commit message" instead of "stop and let the user amend the commit"; and 
if a conflict was found, the sequencer would simply abort and exit with 
a non-zero exit status.

Thanks,

Paolo

Re: [PATCH] provide a new "theirs" strategy, useful for rebase --onto

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

>    #! /bin/sh
>    # git-merge-after-amend <branch>
>    #
>    # Makes it possible to do a fast-forward merge of <branch>
>    # into HEAD, assuming that the first diverging commit of <branch>
>    # is an --amend'ed version of the first diverging commit of HEAD.

Can this strong special case limitation "only the first one can be the
amend" somehow be loosened?  Otherwise I suspect it would not be useful as
a general solution.

Re: [PATCH] provide a new "theirs" strategy, useful for rebase --onto

[Paolo Bonzini]

Junio C Hamano wrote:
> Paolo Bonzini <bonzini@gnu.org> writes:
> 
>>    #! /bin/sh
>>    # git-merge-after-amend <branch>
>>    #
>>    # Makes it possible to do a fast-forward merge of <branch>
>>    # into HEAD, assuming that the first diverging commit of <branch>
>>    # is an --amend'ed version of the first diverging commit of HEAD.
> 
> Can this strong special case limitation "only the first one can be the
> amend" somehow be loosened?

Well, the point of the exercise is to split a *single* commit into a 
"base" commit (already available, possibly on another branch) and a 
"delta" (the amending, transformed into an independent commit whose 
parent is the "base").  Indeed you can do that for any commit.

The script uses the "git-merge-base" to compute the "base", and takes 
the following commit (on the path to HEAD) as the "delta".  That's what 
add the restriction.  You can definitely make a two-argument variation 
that, given arguments "B C" and history

     o--B     (it is irrelevant if B and C have common parents)

     o--o--C--D--E    HEAD

makes

     A--B--C'--D--E

Even in that case, I would make the script (which anyway is obviously 
not meant to be included in git, it's a commodity script) accept both 
variations: one-argument to do the special case, and two-arguments to 
generically split a commit into a base provided by the user + a delta.

Paolo