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
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
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
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
~ianmdlvl / dgit.git / commitdiff