From: manphiz@gmail.com   
      
   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!   
   >   
   > [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   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)