(With permission to reply to list from Aymeric.) Hi Aymeric, Aymeric Agon-Rambosson <aymeric.agon@yandex.com> writes: > Hello, > > Le jeudi 8 janvier 2026 à 16:45, Xiyue Deng <manphiz@gmail.com> a > écrit : > >> Hi Sean, >> >> Sean Whitton <spwhitton@spwhitton.name> writes: >> >>> Hello, >>> >>> Xiyue Deng [07/Jan 6:58pm -08] wrote: >>>> I thought the existence of pristine-tar branch indicates the >>>> workflow. >>> >>> It does, but you're the maintainer now, so it's okay to take steps >>> towards modernisation. >> >> Ack. I think for maintaining max compatibility, we can just mark >> the >> branches `upstream' and `pristine-tar' as read-only by setting >> `Allowed >> to merge' and `Allowed to push and merge' to `No one' instead of >> deleting those branches. This requires one to have a Maintainer >> role >> though. >> >> Also, as there are other magit uploaders, I have CCed them here to >> see >> whether there is any objection to migrate magit to the >> dgit-maint-merge >> workflow. If no objection is received by the end of next week, I'll >> request the Maintainer access and mark the branches read-only. And >> do >> let me know if you want to extend the decision period. > > I prefer the current workflow. You managed to explain it in less than > 20 lines in commit 7061b8aa. > To be clear, if by the "current" workflow you meant what we have been doing in the recent uploads since 4.3.2 (around the time I started working on magit) and before the latest 4.5.0, we actually had been using the dgit-maint-merge workflow effectively. See below. > And it does not even require gbp. You wrote : > >> And then switch to the `master' branch and do the usual `gbp >> import-orig --uscan'. The upstream tag will be `vX.X.X' and the >> Debian upstream tag will be upstream/X.X.X. The pristine-tar branch > > But you can simply go back to the master branch and merge the same tag > you merged to the upstream one : > > ,---- > | $ git branch master && git merge vX.X.X # vX.X.X is the latest > versioned tag > `---- > This is exactly how the dgit-maint-merge workflow works. Notice that this does not involve the Debian "upstream" branch at all. In fact, the last push to the Debian upstream branch before the 4.5.0 release was done at the time when 4.3.1 was released, which was some time after Bookworm and well before Trixie. The problem with the current Debian upstream branch is that it is not exactly the same as the Magit upstream git (and as a result the Debian upstream tag `upstream/X.X.X' is not the exact upstream tag `vX.X.X'), which breaks the expectation of tag2upload[1]. And as I mentioned, we have not been using the Debian upstream branch at all for quite some time before 4.5.0. For the dgit-maint-merge workflow, a maintainer should have an upstream repo setup and merge the tags directly into the Debian master branch, which we have been doing. > If the point is just to use upstream tags and not pristine-tar, then > there is nothing to change to the workflow : just do not commit > anything to the pristine-tar branch. > And AAMOF we didn't commit to the Debian upstream branch either. >> I thought the existence of pristine-tar branch indicates the >> workflow. > > Not necessarily. I never use it, and I forget to commit the tar to the > pristine-tar branch half of the time. > Ack. Same here before I notice the existence of pristine-tar. > Remove the pristine-tar branch if you must (or better yet, just ignore > it), but please leave the upstream branch. > I think by "the upstream branch" you meant the Magit upstream branch? I would make both the Debian upstream and pristine-tar branches read-only to avoid any accidental commits there given the reasoning above. Let me know what you think. > Best, > > Aymeric > Thanks! [1] See also Ian's reply to the long thread regarding including commit id in *.changes where "gbp import-orig --uscan" should be discouraged due to the divergence in the upstream branch: https://lists.debian.org/debian-devel/2026/01/msg00127.html -- Regards, Xiyue Deng
Attachment:
signature.asc
Description: PGP signature