Oxidize NoseyParker

[Byron]

Required Features

(among others that are already implemented)

• a fast way to get the size and kind of an object by ID, by reading only headers, similar to read_header().
• Something like NO_DOT_GIT option to prevent trying two directories if one is given. (open::Options::open_path_as_is() #667)
• a filter to only traverse packed objects if they match a given filter to allow blob-only traversal. (for max performance)
• Generalize git_odb::Store::verify_integrity() so that users can be called on each decoded object to perform their own computation. Not needed, possibly not actually faster.

The first integration PR in the repository and the follow-up.

[bradlarsen]

a filter to only traverse packed objects if they match a given filter to allow blob-only traversal. (for max performance)

This functionality would be generally useful. But in the case of Nosey Parker, though it might speed things up a bit at present, it's a low priority wish list item.

In the longer term, Nosey Parker will also be looking at tree and commit objects to gather precise metadata about blobs with matches (pathnames and the set of commits that first introduced the matching content: praetorian-inc/noseyparker#16. To implement that, in addition to reading every blob, Nosey Parker will also have to read every commit and tree. So at that point, having a gitoxide object filter mechanism would be less useful.

[Byron]

Thanks for letting me know! I think it's best to remove it as a feature requirement alltogether, because even if you'd not be interested in, say, annotated tags, it would make no difference in performance to skip them after they have been decoded, rather than before.

The equivalent to NO_DOT_GIT will land in a moment by the way. Now opening repos is a bit faster as it actually does less IO in the typical case, for typically named repositories, so it's a super nice feature to have.

[Byron]

Awesome, I think everything is done as the last outstanding feature was just merged into main. By the time the new integration branch is ready for merge, I can cut a new release in case you'd like to use that feature and remove the workaround (it's in ca84c87).

[Byron]

I think this task is completed :).

[bradlarsen]

Yes. Thank you for your help!On Sep 4, 2023, at 03:13, Sebastian Thiel ***@***.***> wrote: I think this task is completed :). —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>