From: manphiz@gmail.com   
      
   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   
   >>> to avoid any accidental commits there given the reasoning above.   
   >>>   
   >>> Let me know what you think.   
   >>>   
   >>>> Best,   
   >>>>   
   >>>> Aymeric   
   >>>>   
   >>>   
   >>> Thanks!   
   >>>   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)