Hi!
A regression from 1.0 to 3.0 (quilt) format:

dget https://snapshot.debian.org/archive/debian/20190710T163017Z/pool/main/t/tfortune/tfortune_1.0.0-2.dsc
dget https://deb.debian.org/debian/pool/main/t/tfortune/tfortune_1.0.1-1.dsc
# Sorry for no snapshot.d.o link, it's not there yet.
rm -rf tfortune*/.pc tfortune*/debian/patches

Compare:
debdiff tfortune*dsc
diff -Nurd tfortune-1.0.0/ tfortune-1.0.1/

With debdiff on 1.0 packages, or with regular diff on unpacked source trees,
you get a comparison of the sources that'll be compiled/etc -- ie, anything
that matters for the package's functionality.  But with 3.0, you get only a
diff of the outer container.

The new behaviour may be useful at most for comparing changed patch
metadata, or for debugging quilt-related issues, but not the actual code.

Of course, that's still a valid use case, but answers a different question
that what I'd expect from debdiff.  It's worth keeping as an option for those
debugging quilt problems -- but both coders and release people would want to
diff the contents, thus I'd say the old behaviour should be default, and
that's why I'm reporting this as a regression not a feature.


Meow!
-- Package-specific info:
--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBCHANGE_RELEASE_HEURISTIC=log
DEBSIGN_KEYID=FD9CE2D8D7754B78AB279BBD2C3B436FEAC68101
DSCVERIFY_KEYRINGS="~/.gnupg/pubring.gpg"

[...]

Unless it's 1.0 with any form of patch system that doesn't result in
the changes being applied directly, e.g. dpatch or even quilt.

While you say "no longer", and "new behaviour", I will note that the
code in question has been in debdiff for over a decade. See #475506.

Regards,

Adam

Well yeah, it's not supposed to diff containers recursively.  Looking inside
dpatch is no different from eg. looking inside gcc's tarball-in-tarball.

Or rather: it never had proper support for "3.0 (quilt)" implemented.

#475506 complains about differences showing twice.  And at that point, 3.0
was an early preview, thus a quick hack that got rid of one of the copies
was acceptable.

debdiff is a major part of workflows for many of us; in my case I run it on
every single non-NEW upload I sponsor.  And even when both versions have the
same upstream version, double diffs are pretty hard to read.  So far I only
cursed that but did not investigate the cause -- and only now I realized
that the double diffage doesn't seem to be intended.


Meow!

Control: notforwarded -1
Control: retitle -1 debdiff: show diff to patches twice with --apply-patches
Control: severity -1 minor

I just merged smcv's patch that adds an --apply-patches option (and
related config option), however it's not on by default.
Also it's going to keep repeating the patch diff since it it's not
ignoring the patches by default.

Honestly, I wouldn't like either of them, and there are options to
achieve both of them, so I don't think I want to merge default changes
on that regard, but I'm not going to wontfix this bug just yet.