procedure
filtersout:buf?filters:filter_list?blob:blob?
procedure
filtersout:buf?filters:filter_list?in:buf?
If the in buffer holds data allocated by libgit2 (i.e. in->asize is not zero), then it will be overwritten when applying the filters. If not, then it will be left untouched.
If there are no filters to apply (or filters is NULL), then the out buffer will reference the in buffer data (with asize set to zero) instead of allocating data. This keeps allocations to a minimum, but it means you have to be careful about freeing the in data since out may be pointing to it!
procedure
filtersrepoout:buf?filters:filter_list?repo:repository?path:string?
’path’ is relative to wrokdir
This will return 0 if the given filter is not in the list, or 1 if the filter will be applied.
procedure
( git_filter_list_freefilters)→void?
filters:filter_list?
procedure
( git_filter_list_lengthfl)→integer?
fl:filter_list?
We will attempt to apply all of these filters to any data passed in, but note that the filter apply action still has the option of skipping data that is passed in (for example, the CRLF filter will skip data that appears to be binary).
procedure
blobpathmoderepo:repository?blob:blob?path:string?mode:git_filter_mode_tflags:git_filter_flag_t
This will return 0 (success) but set the output git_filter_list to NULL if no filters are requested for the given file.
repo:repository?mode:git_filter_mode_toptions:git_filter_flag_t
Normally you won’t use this because git_filter_list_load will create the filter list for you, but you can use this in combination with the git_filter_lookup and git_filter_list_push functions to assemble your own chains of filters.
procedure
( git_filter_list_pushflfilterpayload)→integer?
fl:filter_list?filter:filter?payload:bytes?
Normally you won’t have to do this because the filter list is created by calling the "check" function on registered filters when the filter attributes are set, but this does allow more direct manipulation of filter lists when desired.
Note that normally the "check" function can set up a payload for the filter. Using this function, you can either pass in a payload if you know the expected payload format, or you can pass NULL. Some filters may fail with a NULL payload. Good luck!
procedure
blobfilters:filter_list?blob:blob?target:writestream?
procedure
datafilters:filter_list?data:buf?target:writestream?
procedure
repopathfilters:filter_list?repo:repository?path:string?target:writestream?
procedure
( git_filter_registernamefilterpriority)→integer?
name:string?filter:filter?priority:integer?
As mentioned elsewhere, the initialize callback will not be invoked immediately. It is deferred until the filter is used in some way.
A filter’s attribute checks and check and apply callbacks will be issued in order of priority on smudge (to workdir), and in reverse order of priority on clean (to odb).
Two filters are preregistered with libgit2: - GIT_FILTER_CRLF with priority 0 - GIT_FILTER_IDENT with priority 100
Currently the filter registry is not thread safe, so any registering or deregistering of filters must be done outside of any possible usage of the filters (i.e. during application setup or shutdown).
procedure
( git_filter_source_filemodesrc)→integer?
src:filter_source?
procedure
( git_filter_source_flagssrc)→integer?
src:filter_source?
procedure
( git_filter_source_pathsrc)→string?
src:filter_source?
Attempting to remove the builtin libgit2 filters is not permitted and will return an error.
Currently the filter registry is not thread safe, so any registering or deregistering of filters must be done outside of any possible usage of the filters (i.e. during application setup or shutdown).