Hello Xiyue,
Sorry for the late answer, and thank you very much for the
clarifications.
Le mardi 27 janvier 2026 à 16:26, Xiyue Deng <[email protected]> a
écrit :
Hi,
Xiyue Deng <[email protected]> writes:
(With permission to reply to list from Aymeric.)
Hi Aymeric,
Aymeric Agon-Rambosson <[email protected]> writes:
Hello,
Le jeudi 8 janvier 2026 à 16:45, Xiyue Deng
<[email protected]> a
écrit :
Hi Sean,
Sean Whitton <[email protected]> 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 back from Aymeric, but hopefully this
arrangement will
meet his expectation as well.
I'm good as long as you can assure me that the simple workflow I
described on my last mail still works.
Best,
Aymeric
