Thanks for the fix! I'm curious if you have a unit test that you can create that will illustrate this problem?

I ask because after looking at this, and at the other users of git_writestream, the function git_filter_list_stream_data seems inconsistent when it comes to calling close. The close function is used to commit or finish (successfully) the stream.

As a result, it seems that the close should be moved out of the done block entirely... This would match the behavior of (for example) git_filter_list_stream_file. Is my thinking here correct?

I discover this problem when i'm working on rust binding for libgit2. I can provide a unit test later.

The semantics of callbacks in git_writestream is not well-documented, if close is used to commit the stream, I think you're right, close should be moved out of done block.

I find another problem, if you assume 'close' is used to commit a successful stream, in checkout.c, blob_content_to_file, after calling git_filter_list_stream_blob, it asserts writer.open == 0.

It seems to conflict with our assumption? because writer.close should never be called in a failure case.

Fixed via #4196