@@ -34,10 +34,10 @@ internal class GitFilter
3434
3535 /// <summary>
3636 /// Initialize callback on filter
37- ///
37+ ///
3838 /// Specified as `filter.initialize`, this is an optional callback invoked
3939 /// before a filter is first used. It will be called once at most.
40- ///
40+ ///
4141 /// If non-NULL, the filter's `initialize` callback will be invoked right
4242 /// before the first use of the filter, so you can defer expensive
4343 /// initialization operations (in case libgit2 is being used in a way that doesn't need the filter).
@@ -46,7 +46,7 @@ internal class GitFilter
4646
4747 /// <summary>
4848 /// Shutdown callback on filter
49- ///
49+ ///
5050 /// Specified as `filter.shutdown`, this is an optional callback invoked
5151 /// when the filter is unregistered or when libgit2 is shutting down. It
5252 /// will be called once at most and should release resources as needed.
@@ -57,28 +57,28 @@ internal class GitFilter
5757 /// <summary>
5858 /// Callback to decide if a given source needs this filter
5959 /// Specified as `filter.check`, this is an optional callback that checks if filtering is needed for a given source.
60- ///
61- /// It should return 0 if the filter should be applied (i.e. success), GIT_PASSTHROUGH if the filter should
60+ ///
61+ /// It should return 0 if the filter should be applied (i.e. success), GIT_PASSTHROUGH if the filter should
6262 /// not be applied, or an error code to fail out of the filter processing pipeline and return to the caller.
63- ///
63+ ///
6464 /// The `attr_values` will be set to the values of any attributes given in the filter definition. See `git_filter` below for more detail.
65- ///
66- /// The `payload` will be a pointer to a reference payload for the filter. This will start as NULL, but `check` can assign to this
65+ ///
66+ /// The `payload` will be a pointer to a reference payload for the filter. This will start as NULL, but `check` can assign to this
6767 /// pointer for later use by the `apply` callback. Note that the value should be heap allocated (not stack), so that it doesn't go
68- /// away before the `apply` callback can use it. If a filter allocates and assigns a value to the `payload`, it will need a `cleanup`
68+ /// away before the `apply` callback can use it. If a filter allocates and assigns a value to the `payload`, it will need a `cleanup`
6969 /// callback to free the payload.
7070 /// </summary>
7171 public delegate int git_filter_check_fn (
7272 GitFilter gitFilter , IntPtr payload , IntPtr filterSource , IntPtr attributeValues ) ;
7373
7474 /// <summary>
7575 /// Callback to actually perform the data filtering
76- ///
77- /// Specified as `filter.apply`, this is the callback that actually filters data.
76+ ///
77+ /// Specified as `filter.apply`, this is the callback that actually filters data.
7878 /// If it successfully writes the output, it should return 0. Like `check`,
79- /// it can return GIT_PASSTHROUGH to indicate that the filter doesn't want to run.
79+ /// it can return GIT_PASSTHROUGH to indicate that the filter doesn't want to run.
8080 /// Other error codes will stop filter processing and return to the caller.
81- ///
81+ ///
8282 /// The `payload` value will refer to any payload that was set by the `check` callback. It may be read from or written to as needed.
8383 /// </summary>
8484 public delegate int git_filter_apply_fn (
@@ -89,7 +89,7 @@ public delegate int git_filter_stream_fn(
8989
9090 /// <summary>
9191 /// Callback to clean up after filtering has been applied. Specified as `filter.cleanup`, this is an optional callback invoked
92- /// after the filter has been applied. If the `check` or `apply` callbacks allocated a `payload`
92+ /// after the filter has been applied. If the `check` or `apply` callbacks allocated a `payload`
9393 /// to keep per-source filter state, use this callback to free that payload and release resources as required.
9494 /// </summary>
9595 public delegate void git_filter_cleanup_fn ( IntPtr gitFilter , IntPtr payload ) ;
0 commit comments