git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: git@vger.kernel.org
Cc: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Thomas Rast" <trast@student.ethz.ch>,
	"Florian Weimer" <fw@deneb.enyo.de>,
	"Greg Price" <price@ksplice.com>,
	"Jörg Sommer" <joerg@alea.gnuu.de>
Subject: [PATCH] rebase -i -p: document shortcomings
Date: Mon, 31 May 2010 20:43:35 -0500	[thread overview]
Message-ID: <20100601014335.GA21970@progeny.tock> (raw)

The rebase --preserve-merges facility presents a list of commits
in its instruction sheet and uses a separate table to keep
track of their parents.  Unfortunately, in practice this means
that with -p after most attempts to rearrange patches, some
commits have the "wrong" parent and the resulting history is
rarely what the caller expected.

Yes, it would be nice to fix that.  But first, add a warning to the
manual to help the uninitiated understand what is going on.

Reported-by: Jiří Paleček <jpalecek@web.de>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Pointers towards a real fix:

 . http://thread.gmane.org/gmane.comp.version-control.git/79424/focus=79504
 . http://thread.gmane.org/gmane.comp.version-control.git/77965/focus=80835
 . http://thread.gmane.org/gmane.comp.version-control.git/131921/focus=132679
 . http://repo.or.cz/w/git/price.git
 . http://repo.or.cz/w/git/dscho.git/shortlog/refs/heads/rebase-i-p

Thanks to all who have worked on this before.

Thoughts?

 Documentation/git-rebase.txt  |   26 ++++++++++++++++++++++++++
 t/t3404-rebase-interactive.sh |    6 ++++++
 2 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 5863dec..330e9ea 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -306,6 +306,11 @@ link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
 -p::
 --preserve-merges::
 	Instead of ignoring merges, try to recreate them.
++
+This uses the `--interactive` machinery internally, but combining it
+with the `--interactive` option explicitly is generally not a good
+idea (see BUGS below).
+
 
 --root::
 	Rebase all commits reachable from <branch>, instead of
@@ -607,6 +612,27 @@ The ripple effect of a "hard case" recovery is especially bad:
 case" recovery too!
 
 
+BUGS
+----
+The instruction sheet presented by `--preserve-merges --interactive`
+does not represent the topology of the revision graph.  Attempts to
+reorder it tend to produce counterintuitive results.
+
+For example, an attempt to rearrange
+------------
+1 --- 2 --- 3 --- 4 --- 5
+------------
+to
+------------
+1 --- 2 --- 4 --- 3 --- 5
+------------
+by moving the "pick 4" line will result in the following history:
+------------
+        3
+       /
+1 --- 2 --- 4 --- 5
+------------
+
 Authors
 ------
 Written by Junio C Hamano <gitster@pobox.com> and
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index f20ea38..6668907 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -181,6 +181,12 @@ test_expect_success '-p handles "no changes" gracefully' '
 	test $HEAD = $(git rev-parse HEAD)
 '
 
+test_expect_failure 'exchange two commits with -p' '
+	FAKE_LINES="2 1" git rebase -i -p HEAD~2 &&
+	test H = $(git cat-file commit HEAD^ | sed -ne \$p) &&
+	test G = $(git cat-file commit HEAD | sed -ne \$p)
+'
+
 test_expect_success 'preserve merges with -p' '
 	git checkout -b to-be-preserved master^ &&
 	: > unrelated-file &&
-- 
1.7.1

             reply	other threads:[~2010-06-01  1:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-01  1:43 Jonathan Nieder [this message]
2010-06-01  2:22 ` [PATCH] rebase -i -p: document shortcomings Greg Price
2010-06-01  8:50   ` Jonathan Nieder
2010-06-01 11:40   ` Sverre Rabbelier
2010-06-01 17:24     ` Greg Price

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100601014335.GA21970@progeny.tock \
    --to=jrnieder@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=fw@deneb.enyo.de \
    --cc=git@vger.kernel.org \
    --cc=joerg@alea.gnuu.de \
    --cc=price@ksplice.com \
    --cc=trast@student.ethz.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).