IIRC there's a fair bit of cruft along the lines of "remove this deprecated method when the next major version happens" or something like that. I unfortunately haven't been keeping great track of that over time so I don't exactly have a list off-hand. Would you be up for poking around and seeing how much is affected? If you're short on time then I think merging this is fine as well.

I can nuke all of the deprecated stuff. There's a pretty long list in deprecated.h. Do you care about providing deprecated warnings? That is:

• Remove anything already marked #[deprecated]
• Remove anything in libgit-sys that is deprecated in C. I personally don't feel like it is very important to provide deprecation warnings for these, since the number of active users for the raw API is probably close to zero. However, perhaps I am in a surly mood today.
• Remove anything in the git2 crate that is deprecated, even if not using #[deprecated]. There are a few things like the code for generating email-formatted diffs that has fundamentally changed the API. I could maybe see adding deprecations instead of outright removal, but again I feel like the number of users is extremely small.

I can't think of any API breaking changes that are waiting in the wings so to speak. I skimmed the open and closed PRs, but didn't see anything.

Oh I don't mean to cause too much work or anything like that, if we're using deprecated.h that doesn't need to be fixed here. I recall things like foo2 or foo_with_worse_name being added to replace foo because it didn't have a great API or wasn't working for one reason or another, although I'm not sure that these have been tracked with #[deprecated] so it may be pretty manual.

Let's go ahead and merge this and other things can be figured out later

I guess we need to publish a new version of git2-curl. PR is ready: #814