git-debrebase: wip pseudomerge handling

diff --git a/NOTES.git-debrebase-pseudomergehandling b/NOTES.git-debrebase-pseudomergehandling
new file mode 100644 (file)
index 0000000..aa725b1
--- /dev/null
+++ b/NOTES.git-debrebase-pseudomergehandling
@@ -0,0 +1,111 @@
+workflow
+
+  git-debrebase blah [implies start]       strips pseudomerge(s)
+
+  commit / git-debrebase / etc.
+
+  dgit --damp-run push
+      hook: call git-debrebase prep-push   adds new pm ? passes --overwrite ?
+                                           dgit push does not update remote
+
+  commit / git-debrebase / etc.            strips pm(s) including last one
+
+  dgit push
+      hook: call git-debrebase prep-push   adds new pm ? passes --overwrite ?
+                                           dgit push DOES update remote
+
+  commit / git-debrebase / etc.            strips last pm, but arranges
+                                           that remade pm will incorporate it
+
+Aha!
+
+When we strip a pm, we need to maybe record it (or something) as the
+new start point.
+
+We do this if the pm is contained within the output branch.
+
+Actually this is not special to PMs.
+
+We need to record a new to-be-overwritten commit
+   merge-base( our branch tip, relevant remote )
+
+If this is not a descendant of the relevant remote, then we are going
+to have a problem when we push so issue a warning or fail.
+
+
+
+How about
+
+  git-debrebase start or git-debrebase [continue]
+
+    with no recorded will-overwrite
+
+        putative will-overwrite is 
+            one model:
+                our current tip
+                obviously it is safe to say we will overwrite this
+                we do not need to worry about whether this will
+                    overwrite not-included changes in the remote
+                    because either the will-overwrite is not
+                    ff from the remote (in which case later failure,
+                    see below); or the will-overwrite _is_ ff
+                    from the remote ie our tip is later than the
+                    remote and includes all of its changes
+
+                this model tends to keep ad-hoc commits made on our
+                tip branch before we did rebase start, in the
+                `interchange view' and also in the rebase stack.
+
+            other model:
+                merge-base( current remote, current tip )
+
+                it is safe to overwrite current tip, by the
+                argument above
+
+                it is always safe to rewind will-overwrite: all
+                that does is overwrite _less_ stuff
+
+                this is the earliest overwrite we can make that
+                    will be pushable to the remote
+
+                in practical terms this can only be ff from the
+                current remote if it is equal to the current remote;
+                so what we are actually checking below is that our tip
+                is ff from the remote.  This ought to be true before
+                the first of our rebases.
+
+                this model tends to rewind and rebase ad-hoc commits
+                made on our tip branch before we did rebase start,
+                this is better
+
+        in any case putative will-overwrite must be ff from remote.
+        Otherwise when we push it will not be ff, even though we have
+        made pseudomerge to overwrite will-overwrite.  So if we spot
+        this, report an error.
+
+    with a recorded will-overwrite
+
+        we may need to advance will-overwrite, to allow us to generate
+        future pseudomerges that will be pushable
+
+        advancing will-overwrite is dangerous, since it might
+        effectively cancel the commits that will-ovewrite is advanced
+        over.
+
+        we advance it to merge-base( current remote, current tip )
+        if possible (see above), - ie to current remote, subject
+        to the condition that that is an ancestor of current tip
+
+In each case we can strip pseudomerges freely, as needed.  We do not
+want to record what pseudomerges we strip, because whether we need to
+keep them depends (only) on whether they have been pushed.
+
+Is that actually true ?  What if the user actually _wanted_ to keep
+the pseudomerge despite not having pushed it ?
+
+In that case we need to advance will-overwrite past it.  We could
+provide an explicit command to do this: it would advance
+will-overwrite to the current tip (see rules above, which show that
+this is OK).  Or maybe to the last pseudomerge on the current tip,
+so that the overall result will be series of pseudomerges.
+

diff --git a/git-debrebase b/git-debrebase
index 87d605b6e50e7d0a75ef9a0dc5fa74afd077aba0..3469f33d0a0ef285e17d2a04ff34df4ec6fdff66 100755 (executable)
--- a/git-debrebase
+++ b/git-debrebase
@@ -87,11 +87,19 @@
 #  refs/ffqrebase-prev/BRANCH    BRANCH may be refs/...; if not it means
 #  refs/ffqrebase-base/BRANCH      refs/heads/BRANCH
 #                               zero, one, or both of these may exist
-s
+#
 # git-debrebase without start, if already started, is willing
 # to strip pseudomerges provided that they overwrite exactly
 # the previous HEAD
 #  xxxx is this right ?  what matters is have we pushed
+#    I think in fact the right answer is:
+#       git-debrebase always strips out pseudomerges from its branch
+#       a pseudomerge is put in at the time we want to push
+#       at that time, we make a pseudomerge of the remote tracking
+#           branch (if raw git) or the dgit view (if dgit)
+#       for raw git git-ffqrebase, do want preciseley to record
+#           value of remote tracking branch or our branch, on start, so we
+#           overwrite only things we intend to
 #  the previous pseudomerge    check for tags and remote branches ?
 
 use strict;