git-extract doesn't extract from signed tags whose commits are not signed

[apoelstra]

Reading the source, it looks like when you sign a tag it goes through the process of building the whole sha2 binary tree, opentimestamping this, and attaching to the tag. So you can have a repo with no signed commits, only signed tags, and in principle this should be sufficient. You can use this to make a system of "timestamp tags" which checkpoint the state of your repo at various times.

But when using ots git-extract, it reads through the tag to the commit and then complains that there's no timestamp to extract data from.

[petertodd]

That's an interesting point. Though I dunno that it's really worth spending a lot of time supporting a use-case like that. How often do people want timestamped repos. But refuse to sign their code?

[apoelstra]

@petertodd most of the commits in the repo I'm using are produced automatically by git-annex and are not OTS signed. I am not sure if I can configure git-annex to sign commits with OTS and even if I could I'm not sure that I want to because most of its commits are just accounting stuff related to git-annex itself.

Meanwhile, I have a cronjob which produces signed tags nightly. Because this is nightly I even use the mode where it idles until it gets a blockchain timestamp before committing, which takes a couple hours. These tags serve two purposes: one is to provide an easily-searchable "state of my repo on this date" index and the other is to keep deleted files available by some tag so that git-annex won't garbage-collect them even when I tell it to drop unused files. (If my disk gets too full I can easily go back and e.g. delete all the tags older than a year except one per month, or something, then git-annex-dropunused to remove the actual data.)

So, you tell me how much time is worth spending on this very-specific use case :P

[apoelstra]

(Also there's a simple enough workaround; my cronjob just creates an empty commit, OTS-signs that, and then tags the empty commit.)