TODO reference docs git-debrebase(5) data model git-debrebase(1) command line tutorial dgit-maint-debrebase(7) someone should set branch..mergeOptions to include --ff-only ? clean up remains of README arrange for dgit to automatically stitch on push ======================================= special commit tags overall format [git-debrebase[ COMMIT-TYPE [ ARGS...]]: PROSE, MORE PROSE] [git-debrebase: split mixed commit, debian part] [git-debrebase: split mixed commit, upstream-part] [git-debrebase: convert dgit import, debian changes] [git-debrebase anchor: convert dgit import, upstream changes] [git-debrebase upstream-combine . PIECE[ PIECE...]: new upstream] [git-debrebase anchor: new upstream NEW-UPSTREAM-VERSION, merge] [git-debrebase: new upstream NEW-UPSTREAM-VERSION, changelog] [git-debrebase convert-from-gbp: drop patches] [git-debrebase anchor: declare upstream] [git-debrebase pseudomerge: stitch] [git-debrebase convert-to-gbp: commit patches] m{^\[git-debrebase (?:\w*-)?upstream combine \.((?: $extra_orig_namepart_re)+)\]} Every anchor commit must be a merge. In principle, this is not necessary. After all, we are relying on the [git-debrebase anchor: ...] commit message annotation in "declare" anchor merges (which do not have any upstream changes), to distinguish those anchor merges from ordinary pseudomerges (which we might just try to strip). However, the user is going to be doing git-rebase a lot. We really don't want them to rewrite an anchor commit. git-rebase trips up on merges, so that is a useful safety catch. ======================================= workflow git-debrebase blah [implies start] strips pseudomerge(s) commit / git-debrebase / etc. dgit --damp-run push hook: call git-debrebase prep-push dgit push does not update remote or something, must add patches at least commit / git-debrebase / etc. strips patches dgit push hook: call git-debrebase prep-push dgit push DOES update remote commit / git-debrebase / etc. strips last pm, but arranges that remade pm will incorporate it ======================================== Theory for ffq-prev refs/ffq-prev/REF relates to refs/REF When we strip a pm, we need to maybe record it (or something) as the new start point. When we do a thing with no recorded ffq-prev ffq-prev is our current tip 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 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. also we can explicitly preserve with git-debrebase stitch It is always safe to rewind ffq-prev: all that does is overwrite _less_ stuff. 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 ffq-prev. So if we spot this, report an error. see above with a recorded ffq-prev we may need to advance ffq-prev, to allow us to generate future pseudomerges that will be pushable advancing ffq-prev is dangerous, since it might effectively cancel the commits that will-ovewrite is advanced over. ??? 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 currently this is not implemented better maybe to detect divergence ? but it is rather late by then! We check we are ff from remotes before recording new ffq-prev ---------- now follows much the same info in different words ---------- 1. git-debrebase [-i etc.] should: 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 fail check our other might-be-pushed to branches check we are ff from them if not fail set ffq-prev to something which is ff from all above branches we use our tip, as discussed above (optionally, can use some other commit which is ff from all of the above, eg one of them) N. git-debrebase [--noop-ok] record-ffq-prev does what is described above 2. git-debrebase [--noop-ok] stitch makes pseudomerge with ffq-prev deletes ffq-prev we will teach dgit to do git-debrebase stitch or some such ? following parts are not implemented and maybe aren't the best subcommand names etc. 3. git-debrebase push like git push only does stitch first ??? command line parsing! 4. git-debrebase release stiches, finalises changelog, signs tags, pushes everything for the future, when there is some automatic builder ======================================== import from gbp what about dgit view branch ? ideally, would make pseudomerge over dgit view would need to check that dgit view is actually dgit view of ond of our ancestors failing that first push will need --overwrite that is what is currently implemented ======================================== how to handle divergence and merges (if not detected soon enough) same problem if merge, look at branches before merge generate new combined branch pseudomerge to overwrite merge current avaiable strategies: maybe launder foreign branch if foreign branch is nmuish, can rebase it onto ours could merge breakwaters (use analyse to find them) merge breakwaters (assuming same upstream) manually construct new patch queue by inspection of the other two patch queues instead of manually constructing patch queue, could use gbp pq export and git merge the patch queues (ie work with interdiffs) if upstreams are different and one is ahead simply treat that as "ours" and do the work to import changes from the other if upstreams have diverged, can resolve somehow to make new upstream do new-upstream on each branch separately now reduced to previously "solved" problem in future, auto patch queue merge algorithm determine next patch to apply there are three versions o..O, l..L, r..R we have already constructed m (previous patch or merged breakwater) try using vector calculus in the implied cube and compute multiple ways to check consistency ? ======================================== For downstreams of Debian, sketch of git-ffqrebase # git-ffqrebase start [BASE] # # records previous HEAD so it can be overwritten # # records base for future git-ffqrebase # git-ffqrebase set-base BASE # git-ffqrebase # git-ffqrebase finish # git-ffqrebase status [BRANCH]