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