summaryrefslogtreecommitdiff
path: root/NOTES.git-debrebase
diff options
context:
space:
mode:
authorIan Jackson <ijackson@chiark.greenend.org.uk>2018-01-31 18:11:17 +0000
committerIan Jackson <ijackson@chiark.greenend.org.uk>2018-06-16 12:25:49 +0100
commitcdb3884ed9c0a404c956fd0bc3df420ee545debe (patch)
treed053c73358aea75636816daf5fd573d55512b8c5 /NOTES.git-debrebase
parent4f5ea68c4b64ec065e40240e9f0df6ed4279593d (diff)
git-debrebase: rename NOTES to be more generic
Diffstat (limited to 'NOTES.git-debrebase')
-rw-r--r--NOTES.git-debrebase111
1 files changed, 111 insertions, 0 deletions
diff --git a/NOTES.git-debrebase b/NOTES.git-debrebase
new file mode 100644
index 0000000..aa725b1
--- /dev/null
+++ b/NOTES.git-debrebase
@@ -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.
+