Aymeric Agon-Rambosson <[email protected]> writes: > Hello Xiyue, > > Sorry for the late answer, and thank you very much for the > clarifications. > > Le mardi 27 janvier 2026 à 16:26, Xiyue Deng <[email protected]> a > écrit : > >> 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. > > If I understand correctly, does this mean that our upstream branch > remains after all ? >
Yes. Though I believe it is different from what you were referring to: if you were using "git checkout master && git merge vX.X.X", the tag you are merging from is from the Magit upstream branch, not Debian upstream branch. This is the dgit-maint-merge workflow, in which only the `master' (or debian/latest as in DEP-14) is used; no Debian upstream branch is actually used here[1]. >> 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. > > I'm good as long as you can assure me that the simple workflow I > described on my last mail still works. > It would be different though: dgit-maint-merge workflow will directly use upstream main branch and upstream tags; while `gbp import-orig --uscan' will create new commits in the Debian upstream branch, making it diverging from upstream main branch. Let me try to make it clearer by using Magit branching graph. An example for dgit-maint-merge workflow will look like below (using an example from magit packaging): ,----[ dgit-maint-merge workflow ] | 160c8a40 * Merge tag 'v4.4.2' | |\ | b828afbb | * v4.4.2 Release version 4.4.2 `---- Notice that we directly merge the upstream tag `v4.4.2' (b828afbb) into our Debian `master' branch (160c8a40). No actual Debian upstream branch is involved. On the other hand, using `gbp import-orig --uscan' with `upstream-vcs-tag' will look like below (example from emacs-corfu packaging): ,----[ `gbp import-orig --uscan' with `upstream-vcs-tag' ] | 077e35b * Merge tag 'upstream/2.8' into debian/master | |\ | 4680970 | * upstream/2.8 debian/upstream/latest New upstream version 2.8 | | |\ | fbbcdf9 | | * 2.8 upstreamvcs/main Version 2.8 `---- Notice that `2.8' is the upstream tag. After running `gbp import-orig --uscan --upstream-vcs-tag=%(version)s', it will create a no-change commit in the Debian upstream branch (4680970) from the upstream branch (fbbcdf9), add a Debian tag `upstream/2.8', and then merge into our debian/master branch (077e35b). Though this may cause a divergence in our Debian upstream branch compared to upstream main branch, it should be harmless and still compatible with tag2upload[2]. I believe you prefer the first alternative which is also what I'm proposing now. Other people more familiar with gbp may prefer the second workflow. Note that since the divergence in Debian upstream over upstream main branch has already happened, so it may no longer be identify anymore, so if we want to keep using the Debian upstream branch, we have to use the second workflow or something comparable. Personally I don't have a strong preference. It would be great to hear which one people would prefer. > Best, > > Aymeric > [1] Well, there is a possibility that the Debian upstream (or upstream/latest as in DEP-14) branch is exactly the same as upstream main branch, in which case there is no difference. [2] You do have to specify which upstream tag to use as the contents of both tags are identical. Using either is fine, and I think Ian prefers the upstream one over the Debian one. -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
