Didier 'OdyX' Raboud <o...@debian.org> writes: > Le vendredi, 28 juin 2024, 08.32:43 h CEST Ansgar ๐ a รฉcrit : >> I'll expand on the here slightly for your benefit: >> >> $ git clone https://salsa.debian.org/rra/tf5.git >> [...] >> $ apt-get source tf5 >> [...] >> $ rm -rf tf5/.git tf5-5.0beta8/.pc >> $ diff -Nur tf5 tf5-5.0beta8; echo $? >> 0 >> >> If one is really bored: >> $ (cd tf5; sha256sum $(find . -type f | sort) | sha256sum -) >> 8d7820471fb44382a0c752319906064a1276ff18873fb4730dec1319aaf7b459 - >> $ (cd tf5-5.0beta8; sha256sum $(find . -type f | sort) | sha256sum -) >> 8d7820471fb44382a0c752319906064a1276ff18873fb4730dec1319aaf7b459 - >> >> I will leave it as an exercise to you to compare the output and to >> reason about results of different ways to compare both trees.
> It looks to me that you have taken (by choice, or by chance) an example > that too conveniently fits what you want to demonstrate: in which the > git repository and the .dsc are treesame. They are often the case, but > not always, as documented in the various git workflows' documentation > provided by dgit. The salsa repo can be patches-applied and not have > the debian/patches files, they'd be created at dgit push-source time. The initial confusion about this is my fault. I was the one who offered tf5 as an example; Ansgar didn't choose it. tf5 uses a git-debrebase workflow, which means that debian/patches has to be synthesized from Git commits. What I missed, much to my embarrassment, is that since tag2upload doesn't exist, I am using dgit locally, and the default dgit behavior with git-debrebase workflows is to generate all of debian/patches locally and commit them to Git before doing the package upload. So it *looks* from the current Git state like I am maintaining a debian/patches directory in Git that would be available to tag2upload. This isn't actually the behavior that I wanted and I had not realized that it was doing this. It's was a configuration error on my part. I've now fixed that configuration and pushed a new version so that people can see what I had intended the behavior to be. Note the difference between the debian/5.0beta8-13 tag (what I would tag with tag2upload) and the archive/debian/5.0beta8-13 tag (what the tree looks like after the processing that tag2upload would perform). However, more relevant to this discussion, tf5 even with the previous configuration only looks like it's a trivial case because I can't use tag2upload and therefore I am still using a thick client (dgit) locally to upload. That means that dgit can manipulate my local Git tree before doing the upload to do a bunch of Debian-specific work. As soon as I start using tag2upload, I am no longer running dgit locally and that patch generation will be represented in the Git tree that I sign to trigger tag2upload. Ian explained all of this in an excellent and comprehensive message that he sent in reply to mine, correcting my misunderstandings about how this workflow worked. (Hopefully I have it right now!) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
