chiark / gitweb /
git-debrebase: NOTES: reword to record decisions about pm and ffq handling
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Sun, 18 Feb 2018 14:47:02 +0000 (14:47 +0000)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Sat, 16 Jun 2018 15:06:59 +0000 (16:06 +0100)
NOTES.git-debrebase

index b4ffdda..8613e40 100644 (file)
@@ -91,118 +91,67 @@ workflow
   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
+Theory for ffq-prev
 
-  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
+When we strip a pm, we need to maybe record it (or something) as the
+new start point.
 
-                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.
+When we do a thing
 
-            other model:
-                merge-base( current remote, current tip )
+    with no recorded ffq-prev
 
-                it is safe to overwrite current tip, by the
-                argument above
+        ffq-prev is our current tip
 
-                it is always safe to rewind will-overwrite: all
-                that does is overwrite _less_ stuff
+        obviously it is safe to say we will overwrite this
+        we do check whether there are not-included changes in the remotes
+        because if the new ffq-prev is not ff from the remotes
+        the later pushes will fail
 
-                this is the earliest overwrite we can make that
-                    will be pushable to the remote
+        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.
 
-                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.
+        also we can explicitly preserve with
+        git-debrebase stitch
 
-                this model tends to rewind and rebase ad-hoc commits
-                made on our tip branch before we did rebase start,
-                this is better
+       It is always safe to rewind ffq-prev: all
+       that does is overwrite _less_ stuff.
 
-        in any case putative will-overwrite must be ff from remote.
+        in any case putative ffq-prev 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.
+        made pseudomerge to overwrite ffq-prev.  So if we spot
+        this, report an error.  see above
 
-    with a recorded will-overwrite
+    with a recorded ffq-prev
 
-        we may need to advance will-overwrite, to allow us to generate
+        we may need to advance ffq-prev, to allow us to generate
         future pseudomerges that will be pushable
 
-        advancing will-overwrite is dangerous, since it might
+        advancing ffq-prev 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 )
+        ??? 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.
+        currently this is not implemented
 
-Is that actually true ?  What if the user actually _wanted_ to keep
-the pseudomerge despite not having pushed it ?
+        better maybe to detect divergence ?  but it is rather late
+        by then!
 
-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.
+We check we are ff from remotes before recording new ffq-prev
 
 ========================================
 
-So, pm handling specifics:
-
-strategy is to avoid making needless pseudomerges
-pseudomerges that exist will be preserved
-(by being included in will-overwrite)
-
-This is good because the presence of a pseudomerge means we know we
-want to keep it; and that allows explicit control over history detail
-level.
-
-It does mean we must avoid making the pseudomerges unnecessarily.
-They should be made just before (ideally, part of) dgit push.
-
 1. git-debrebase [-i etc.]
 
      should:
-        check for will-overwrite
-        if is already a will-overwrite, fine, do no more
+        check for ffq-prev
+        if is already a ffq-prev, fine, do no more
         if not:
 
         check our origin branch exists and we are ff from it
@@ -212,7 +161,7 @@ They should be made just before (ideally, part of) dgit push.
         check we are ff from them
         if not fail
 
-        set will-overwrite to something which is ff from
+        set ffq-prev to something which is ff from
           all above branches
 
         we use our tip, as discussed above
@@ -225,8 +174,8 @@ N. git-debrebase [--noop-ok] record-ffq-prev
 
 2. git-debrebase [--noop-ok] stitch
 
-    makes pseudomerge with will-overwrite
-    deletes will-overwrite
+    makes pseudomerge with ffq-prev
+    deletes ffq-prev
 
     we will teach dgit to do
        git-debrebase stitch
@@ -241,7 +190,7 @@ N. git-debrebase [--noop-ok] record-ffq-prev
     stiches, finalises changelog, signs tags, pushes everything
     for the future, when there is some automatic builder
 
-will-overwrite for each ref
+ffq-prev for each ref
     refs/heads/FOO
 is
     refs/ffq-prev/FOO