The warning I included might make this feature hard-to-use: but people are clever, and there are ways around it, which also grant other useful properties to smudge- and clean- filters. For instance, if you add at the beginning of each file you filter, you add GITTATTRIBUTES_FILTERED_VERSION_1, that grants the "no double clean" property and allows for versioning of the script. To do this perfectly, you'd want to let the user declare the script file, and then have git figure out what version of it to run. But that would take an understanding of the conversion code which I lack, and would also be a lot of a work for a little-used addition to an underused feature. Signed-off-by: Calum McConnell <calumlikesapplepie@xxxxxxxxx> --- Documentation/gitattributes.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 83fd4e19a4..33b0087d4f 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -486,6 +486,19 @@ not exist, or may have different contents. So, smudge and clean commands should not try to access the file on disk, but only act as filters on the content provided to them on standard input. +Sequence "%w" on the filter command line is replaced with the absolute path +to the root of the repository working tree. This is useful if you have +complex scripts specific to your project. Note that these scripts should +be mostly static for the life of the project, since the script version that +is run may significantly predate or follow the version of the file being +processed + +------------------------ +[filter "unzip-file"] + clean = %w/scripts/filter-unzip-clean + smudge = %w/scripts/filter-unzip-smudge +------------------------ + Long Running Filter Process ^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- 2.30.2
