git-debrebase: merge: Comment about laundry of merge of unstitched

I have concluded that this is not a problem avoidable by
git-debrebase, and that any trouble will be tolerable (at least, not
data loss).  The user should try to avoid doing this.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

2 files changed, 10 insertions, 8 deletions

diff --git a/git-debrebase b/git-debrebase
index c463f4a..2b257dd 100755
--- a/git-debrebase
+++ b/git-debrebase
@@ -1082,8 +1082,16 @@ sub walk ($;$$$) {
 	    }
 	    die "$ty ?";
 	} elsif ($ty eq 'VanillaMerge' or $ty eq 'MergedBreakwaters') {
-	    # xxx need to handle ffq if one side was unstitched
-	    # wait both of them may be!
+	    # User may have merged unstitched branch(es).  We will
+	    # have now lost what ffq-prev was then (since the later
+	    # pseudomerge may introduce further changes).  The effect
+	    # of resolving such a merge is that we may have to go back
+	    # further in history to find a merge base, since the one
+	    # which was reachable via ffq-prev is no longer findable.
+	    # This is suboptimal, but if it all works we'll have done
+	    # the right thing.
+	    # xxx we should warn the user in the docs about this
+
 	    my $ok=1;
 	    my $best_anchor;
 	    # We expect to find a dominating anchor amongst the
diff --git a/tests/tests/gdr-merge b/tests/tests/gdr-merge
index 25b2ee0..baffedf 100755
--- a/tests/tests/gdr-merge
+++ b/tests/tests/gdr-merge
@@ -59,12 +59,6 @@ t-git-debrebase scrap
 t-some-changes after
 t-git-debrebase
 
-# xxx want to check that we DTRT if we start out unstitched -
-# xxx should consider our ffq-prev as a parent
-# xxx or should we ?  it's not a parent of the merge is it ?
-# xxx => user should prefer to make merges when stitched ?
-# xxx think about this later
-
 # t-gdr-good laundered
 # xxx ^ this does not work