If one uses `git debpush --gbp` for a tree where dgit can already detect
that the package uses gbp-pq(1) patches (I think by looking at the last
tag in the history?), then the tool complains at you that the option was
superfluous.  A comment indicates that this is to get people into the
habit of just typing `git debpush` for their regular uploads.

However, if one is obediently in that habit, then uploads can fail as
shown in the forwarded email.  The previous upload of pydantic
(2.13.4-1) had no patches and so dgit did not require any kind of
--quilt argument.  2.13.4-2 added patches.  I used `git debpush`, which 
appeared completely happy on the client side, but resulted in a failure
from tag2upload.

Right now, it is in practice safer for users who know that their package
either uses gbp-pq(1) now or would use it if it had any patches (due to
team policy or whatever) to always use `git debpush --gbp` and ignore
the warning.  It seems that that isn't what you want, though, so I think
`git debpush` needs to detect the situation where the previous tag had
no quilt mode but the current tag requires one.

Thanks,

Colin Watson [28/Jun  4:34pm +01] wrote:

To clarify one thing immediately, there is always a quilt mode for
tag2upload because we are always in dgit's split-brain mode.

The failed upload for 2.13.4-2 used --quilt=linear.

It looks like git-debpush chose --quilt=linear for 2.13.4-2.  It would
have done that because the most recent upload to sid before was 2.13.4-1
which has --quilt=linear, probably because you used dgit without an
explicit quilt mode and there were upstream changes (dgit has a default
quilt mode, tag2upload does not).

git-debpush's autodetection saw that dgit upload and selected
--quilt=linear for the failed upload.  Then in addition, the check for
whether or not the patches apply wasn't run at all, because it doesn't
run for --quilt=linear.  So you didn't get a client-side failure.

I think maybe we can fix this by just extending the patch application
check to more quilt modes, or adding a similar check.

Also if we implement #1111423 dgit would have chosen --gbp so the
problem wouldn't have occurred.

Sean Whitton writes ("Bug#1140941: git-debpush: Forgetting --gbp when a package previously had no patches can result in irrecoverable tags"):

Right.

When to pass --gbp can be rather subtle.  Assuming you're using gbp
branch format:

When running dgit, --gbp is is always required.  If you omit --gbp
when running dgit, your upload can succeed while making metadata that
causes a future upload with tag2upload to fail.

When running git-debpush, --gbp is sometimes optional, but right now
if you pass it when it's not needed, you get a failed check.

I would ideally like to advise users who are sometimes using
git-debpush and sometimes using dgit, to always pass --gbp
(when the package is maintained in git with patches -unapplied).
That is easy to remember and avoids lossage.  But right now that often
produces a failed check from git-debpush.  In May in I proposed to
downsgrade that check, but the dixcussion has not yet converged:
https://salsa.debian.org/dgit-team/dgit/-/merge_requests/497

I don't think this is quite right.  There's always a quilt mode with
"3.0 (quilt)", regardless of whether it's local dgit or tag2upload,
and regardless of split brain.  With "3.0 (native)" and 1.0, there is
no quilt mode, even with split brain (as in tag2upload).

I think adding such a check is a good idea.  In the current instance
it would have detected the problem earlier, while trying to make the
-2 tag.  But I'm not sure I would call this a "fix" - the wrong quilt
mode was already baked into the tag made for the -1 upload.  Ideally
we would have avoided that somehow.

Yes, assuming that the last upload prior to 2.13.4-1 used dgit or
tag2upload and had the right quilt mode.

#1111423 seems nontrivial to me.  So I think git-debpush and dgit
are going to have different behaviour for some time yet.

Ian.