On Mon, Feb 27, 2023 at 03:26:52PM +0100, Alejandro Colomar wrote: > On 2/27/23 13:56, G. Branden Robinson wrote: > > At 2023-02-26T13:30:58+0000, Colin Watson wrote: > >> First, move your current branch somewhere for reference, then make a new > >> one. Then, my routine for pulling in new upstreams looks roughly like > >> this: > >> > >> git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched > >> ../foo.orig.tar.gz > >> # this imports the unpacked upstream tarball onto an upstream branch > >> # based on $UPSTREAMTAG, then drops you into a rebase session > >> > >> ... continue with rebase as needed, then once you're finished ... > >> > >> git-dpm update-patches --amend > >> # the --amend is just because the import-new-upstream step will > >> # already have recorded the new upstream on the branch you started > >> # from, but the history looks clearer if you bundle the rebase with > >> # that in a single merge commit, which this does > > May I ask something from you, Colin? Could you please embed that > info in the commit messages in salsa? That would help those who > want to learn Debian packaging from actual practice rather than > tutorials (I've read and watched many of those, and my confusion > only grows; I mean, just look at > <https://www.youtube.com/watch?v=O83rIRRJysA> :p). > > In the Linux man pages I write the scripts or commands run to produce > a scripted or semi-scripted patch, or when some important information > needed to write a patch was gotten from some script. See for example:
This isn't really analogous to your situation, though. git-dpm is more like a workflow tool (such as stgit) than it is like a program you use to generate one-off scripted patches. I don't think it would be appropriate or reasonable to try to embed this sort of thing in every commit generated by git-dpm, which is quite a lot of the commits that end up in my packaging branches. I'd be happy to write a debian/README.source file, which would be a better place for this sort of thing. I'm not sure exactly when I'll get round to it, but I've added it to my to-do list. > > Please find attached my much more modest proposal. Let's make sure the > > groff in Debian bookworm will not throw confusing undefined register > > warnings or drop text from man pages that begin to embrace groff 1.23's > > new features. I'm fine with this, modulo sorting out minor commit formatting details. -- Colin Watson (he/him) [cjwat...@debian.org]