From: Ian Jackson Date: Fri, 28 Apr 2017 16:41:38 +0000 (+0100) Subject: git-debrebase: wip pseudomerge handling X-Git-Tag: archive/debian/5.0~361 X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=commitdiff_plain;h=9f13c444cdf81783a383787f3b8ae5deedbd59d7 git-debrebase: wip pseudomerge handling --- diff --git a/NOTES.git-debrebase-pseudomergehandling b/NOTES.git-debrebase-pseudomergehandling new file mode 100644 index 00000000..aa725b13 --- /dev/null +++ b/NOTES.git-debrebase-pseudomergehandling @@ -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. + diff --git a/git-debrebase b/git-debrebase index 87d605b6..3469f33d 100755 --- a/git-debrebase +++ b/git-debrebase @@ -87,11 +87,19 @@ # refs/ffqrebase-prev/BRANCH BRANCH may be refs/...; if not it means # refs/ffqrebase-base/BRANCH refs/heads/BRANCH # zero, one, or both of these may exist -s +# # git-debrebase without start, if already started, is willing # to strip pseudomerges provided that they overwrite exactly # the previous HEAD # xxxx is this right ? what matters is have we pushed +# I think in fact the right answer is: +# git-debrebase always strips out pseudomerges from its branch +# a pseudomerge is put in at the time we want to push +# at that time, we make a pseudomerge of the remote tracking +# branch (if raw git) or the dgit view (if dgit) +# for raw git git-ffqrebase, do want preciseley to record +# value of remote tracking branch or our branch, on start, so we +# overwrite only things we intend to # the previous pseudomerge check for tags and remote branches ? use strict;