From: Ian Jackson Date: Sun, 18 Feb 2018 14:47:02 +0000 (+0000) Subject: git-debrebase: NOTES: reword to record decisions about pm and ffq handling X-Git-Tag: archive/debian/5.0~123 X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=commitdiff_plain;h=0294b9e9d45cb4360674ea90a39d630153a94aea git-debrebase: NOTES: reword to record decisions about pm and ffq handling --- diff --git a/NOTES.git-debrebase b/NOTES.git-debrebase index b4ffdda2..8613e407 100644 --- 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 -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