Re: Accepted magit 4.5.0-1 (source) into unstable
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 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-
Re: Accepted magit 4.5.0-1 (source) into unstable
Hello, Xiyue Deng [27/Jan 4:26pm -08] wrote: > 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. Compatible but not recommended. -- Sean Whitton
Re: Accepted magit 4.5.0-1 (source) into unstable
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! >>> >>> [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
Re: Accepted magit 4.5.0-1 (source) into unstable
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! [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 ? 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
Re: Accepted magit 4.5.0-1 (source) into unstable
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 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
Re: Accepted magit 4.5.0-1 (source) into unstable
(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 -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Accepted magit 4.5.0-1 (source) into unstable
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. Thanks! -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Accepted magit 4.5.0-1 (source) into unstable
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. -- Sean Whitton
Re: Accepted magit 4.5.0-1 (source) into unstable
Hi Sean, Sean Whitton writes: > Hello, > > Debian FTP Masters [07/Jan 4:19am GMT] wrote: >> Format: 1.8 >> Date: Tue, 06 Jan 2026 18:38:33 -0800 >> Source: magit >> Architecture: source >> Version: 4.5.0-1 >> Distribution: unstable >> Urgency: medium >> Maintainer: Debian Emacsen team >> Changed-By: Xiyue Deng >> Changes: >> magit (4.5.0-1) unstable; urgency=medium >> . >>* New upstream release >>* Update d/gbp.conf to use pristine-tar + upstream history workflow >> - The repo actually has both upstream and pristine-tar branches. It >>is better to keep using them for now. > > I'd prefer just using upstream tags. You can delete the pristine-tar > and upstream branches. I thought the existence of pristine-tar branch indicates the workflow. Personally I prefer the dgit-maint-merge workflow anyway which is also tag2upload compatible. I have now updated d/gbp.conf and d/README.source to refer to the dgit-maint-merge workflow. I haven't deleted the branches yet, because I'm not sure whether the previous releases that did use pristine-tar could be broken. Though I guess we can always get the correct archives either through previous .dsc from the archive (or snapshot) or from dgit. If that is indeed the case, deleting the branches should be no problem. -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Accepted magit 4.5.0-1 (source) into unstable
Hello, Debian FTP Masters [07/Jan 4:19am GMT] wrote: > Format: 1.8 > Date: Tue, 06 Jan 2026 18:38:33 -0800 > Source: magit > Architecture: source > Version: 4.5.0-1 > Distribution: unstable > Urgency: medium > Maintainer: Debian Emacsen team > Changed-By: Xiyue Deng > Changes: > magit (4.5.0-1) unstable; urgency=medium > . >* New upstream release >* Update d/gbp.conf to use pristine-tar + upstream history workflow > - The repo actually has both upstream and pristine-tar branches. It >is better to keep using them for now. I'd prefer just using upstream tags. You can delete the pristine-tar and upstream branches. -- Sean Whitton
