Ian Jackson <[email protected]> writes: > It's a long time ago, but my memory of the reason I wrote this in dgit > is as follows. I saw the frequent presence of packages with changes > to the toplevel .gitignore, but without any patch for that. > I inferred, perhaps wrongly, that gbp-based workflows are *supposed* > to omit such patches. > > I experimentally removed this error check from my local dgit. When I > did that it was able to build a .dsc (and it passed the new git==dsc > correspondence check). > > I propose that rather than changing git-debpush to detect this > situation, we change dgit (and thus the tga2upload service) to accept > it. > > Then --quilt=unapplied will be (just) for people who want to *insist* > that their maintainer git tree *does* contain such patches, and > --quilt=gbp will tolerate it either way. > > Sean, Simon, what do you think?
I have no preference here. I have had a long-term mental todo item to understand what on earth is happening with top-level .gitignore in the intersection between gbp vs dgit vs Go's dh-make-golang defaults. But as this does not seem to trigger any critical failure (until now) and no QA tool complain about it (except possibly the PTS patch queue notifier), I've tended to just ignore it as yet another weird thing. Is what is triggering this to happen the following patch? https://salsa.debian.org/python-team/packages/python-securesystemslib/-/blob/debian/latest/debian/patches/02_rm_vendored_gitignore.diff?ref_type=heads I don't understand what problem the patch is trying to solve, so I could try to just remove it and see if anything breaks. Or make some other changes to the git packaging on Salsa to make tag2upload behave smoother. /Simon
signature.asc
Description: PGP signature
