chiark / gitweb /
git-debrebase: merge: Comment about laundry of merge of unstitched
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Sat, 11 Aug 2018 10:43:40 +0000 (11:43 +0100)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Sat, 11 Aug 2018 10:43:40 +0000 (11:43 +0100)
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>
git-debrebase
tests/tests/gdr-merge

index c463f4a..2b257dd 100755 (executable)
@@ -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
index 25b2ee0..baffedf 100755 (executable)
@@ -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