X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=blobdiff_plain;f=NOTES.git-debrebase;h=bd6e7151221f67ff54e6100f629c23ce58afaa55;hp=b7552b7024af19bf969af7c33152b1e9de60baab;hb=0c244082ddb4b2443ccfbc1c438ead4fda1c33ca;hpb=21743f5f7c82d130d69fe12ba1faa7ac816e1a68 diff --git a/NOTES.git-debrebase b/NOTES.git-debrebase index b7552b70..bd6e7151 100644 --- a/NOTES.git-debrebase +++ b/NOTES.git-debrebase @@ -1,82 +1,28 @@ -TODO - reference docs - 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 - - - - -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 - - - -# undocumented usages: -# -# git-debrebase [] downstream-rebase-launder-v0 # experimental - # problems / outstanding questions: # -# * dgit push with a `3.0 (quilt)' package means doing quilt -# fixup. Usually this involves recommitting the whole patch -# series, one at a time, with dpkg-source --commit. This is -# terribly terribly slow. (Maybe this should be fixed in dgit.) -# -# * dgit push usually needs to (re)make a pseudomerge. The "first" -# git-debrebase stripped out the previous pseudomerge and could -# have remembeed the HEAD. But it's not quite clear what history -# ought to be preserved and what should be discarded. For now -# the user will have to tell dgit --overwrite. -# -# To fix this, do we need a new push hook for dgit ? -# -# * Workflow is currently clumsy. Lots of spurious runes to type. -# There's not even a guide. -# -# * new-upstream-v0 has a terrible UI for multiple upstream pieces. +# * new-upstream has an awkward UI for multiple upstream pieces. # You end up with giant runic command lines. Does this matter / +# One consequence of the lack of richness it can need -f in +# fairly sensible situations. # -# One consequence of the lack of richness it can need --force in -# fairly sensible situations and there is no way to tell it what -# you are really trying to do, other than just --force. There -# should be an interface with some default branch names. -# -# * There should be a standard convention for the version number, +# * There should be a good convention for the version number, # and unfinalised or not changelog, after new-upstream. # # * Handing of multi-orig dgit new-upstream .dsc imports is known to # be broken. They may be not recognised, improperly converted, or # their conversion may be unrecognised. # -# * Docs need writing and updating. Even README.git-debrebase -# describes a design but may not reflect the implementation. -# # * We need to develop a plausible model that works for derivatives, # who probably want to maintain their stack on top of Debian's. # downstream-rebase-launder-v0 may be a starting point? +# maybe the hypothetical git-ffqrebase is part of it too. +# undocumented usages: +# +# git-debrebase [] downstream-rebase-launder-v0 # experimental + + ======================================== Theory for ffq-prev @@ -132,38 +78,6 @@ When we do a thing We check we are ff from remotes before recording new ffq-prev - ---------- now follows much the same info in different words ---------- - -Re git-debrebase [--noop-ok] stitch - - 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)