git-debrebase: NOTES: reword to record decisions about pm and ffq handling

[dgit.git] / NOTES.git-debrebase

diff --git a/NOTES.git-debrebase b/NOTES.git-debrebase
index b4ffdda23e760a98b165873470d9b8b6c4967f72..8613e407bce54654f5a3363ecd9bdef99217cea7 100644 (file)
--- a/NOTES.git-debrebase
+++ b/NOTES.git-debrebase
@@ -91,118 +91,67 @@ workflow
   commit / git-debrebase / etc.            strips last pm, but arranges
                                            that remade pm will incorporate it
 
   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
         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
 
         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.
 
         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
 
         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:
 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
         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
 
         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
           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
 
 
 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
 
     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
 
     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
     refs/heads/FOO
 is
     refs/ffq-prev/FOO