From: manphiz@gmail.com   
      
   Xiyue Deng  writes:   
      
   > Aymeric Agon-Rambosson  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  a   
   >> écrit :   
   >>   
   >>> Hi,   
   >>>   
   >>> Xiyue Deng  writes:   
   >>>   
   >>>> (With permission to reply to list from Aymeric.)   
   >>>>   
   >>>> Hi Aymeric,   
   >>>>   
   >>>> Aymeric Agon-Rambosson  writes:   
   >>>>   
   >>>>> Hello,   
   >>>>>   
   >>>>> Le jeudi 8 janvier 2026 à 16:45, Xiyue Deng  a   
   >>>>> écrit :   
   >>>>>   
   >>>>>> Hi Sean,   
   >>>>>>   
   >>>>>> Sean Whitton  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   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)