On 17277 March 1977, Ian Jackson wrote:
Firstly, you say a "shallow clone".
It is not straightforward to include *precisely* the set of commits that are required to reproduce the output. The conversion might, in principle, go arbitrarily far into the maintainer's packaging branch; and, if the conversion involves an external tool such as git-debcherry, that tool probably won't currently report what commit(s) it used - so would need to be modified.
I'm hoping the reason you say "shallow clone" is simply to avoid bloat.
Yes.
In that case, it's fairly simple: I find it difficult to imagine a future workflow that includes the history *of the upstream branch*. So the t2u server could exclude commits which are in the history of the nominated upstream tag. That would generally do the right thing, but it wouldn't *guarantee* not to include unwanted history. Would that be OK ?
Yes.
Secondly, the file listing. Thanks for the explanation. I'm still not quite sure we understand why you want it. Even so, I think I have a possible way to eliminate it, while still giving you the property that dak (or a future audit) can know the file list of the tree signed by the maintainer, without needing to actually run git. (I'm guessing that having dak not run git is why you don't think it's good enough that one can verify the contents directly from the git tag by running the git-ls-files rune.) The git tag is itself a Merkle tree, containing the information you need. So the hashes of all these things, and the filenames, are already signed by the maintainer - that's the git tag. The reason it's not readily verifiable without running git itself, is mostly because getting the actual object texts out of git is very complicated. How about we (the tag2upload team):
[... long description ...] Honestly I think that sounds way more complicated than a "git ls-files something" based file and process, and binds us more tightly to actual git than ls-files does (one could easily have more fields in there, if deemed neccessary). But I don't see anything obviously so wrong that its a NO, so fine.
The new listing program could be written in the language of your choice. (I'm volunteering to write it.)
While I personally love Rust nowadays, dak is python, so python that will be. (While it won't be integrated into dak (so easier for others to take), it should share the same language). -- bye, Joerg
