Hi, Xiyue Deng <[email protected]> writes:
> (With permission to reply to list from Aymeric.) > > Hi Aymeric, > > Aymeric Agon-Rambosson <[email protected]> writes: > >> Hello, >> >> Le jeudi 8 janvier 2026 à 16:45, Xiyue Deng <[email protected]> a >> écrit : >> >>> Hi Sean, >>> >>> Sean Whitton <[email protected]> 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 On reading the recent debate on d-d@, I saw one proposal that suggested to add "upstream-vcs-tag" to d/gbp.conf. With this, `gbp import-orig --uscan' will import the full upstream history with a no-change commit (either to the tag or HEAD) to our upstream branch. This seems to be very close to the dgit-maint-merge workflow and people can still use `gbp import-orig --uscan'. We can also stop using pristine-tar (right after my previous silly attempt) for good and things should continue to work. I think this is also compatible with tag2upload, though one may need to specify which upstream tag to use when running `git debpush' since this may create 2 upstream tag: one like `v?%(version)s' and one like `upstream/%(version)s'. (Adding Sean to CC to confirm whether the above is true or is recommended.) I haven't heard back from Aymeric, but hopefully this arrangement will meet his expectation as well. -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
