Git Clean Filter Breaking on Empty Files

Question

I setup the following filters from the Git Attributes documentation:

git config filter.dater.smudge expand_date
git config filter.dater.clean 'perl -pe s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'

Now I run the following commands:

touch nfile.txt
git add --all

And get the following error:

error: copy-fd: read returned Bad file descriptor
error: cannot feed the input to external filter perl -pe "s/\\\$DATE[^\\\$]*\\\$/\\\$DATE\\\$/"
error: external filter perl -pe "s/\\\$DATE[^\\\$]*\\\$/\\\$DATE\\\$/" failed

The error does not appear to be related to my script because if I run this I get no errors:

cat nfile.txt | perl -pe "s/\\\$DATE[^\\\$]*\\\$/\\\$DATE\\\$/"

Further, this old thread mentions that the error could possibly be due to "copy_fd in code called from apply_filter" and recommended to patch the function filter_buffer_or_fd in th git core file convert.c. Personally, if I could avoid patching core Git code I would be very happy.

I need to clean up the error messages because I do not want users to see this ugly sort of output during the staging phase of their commits. Is there a way to avoid this? or correct way of handling this situation?

If this has been answered before, I apologize. I could not find an equivalent article on exchange or the internet.

Answer 1

Git 2.5+ should get more robust with empty files when processed by clean/smudge content filter drivers.

See commit f6a1e1e by Jim Hill (jthill), 18 May 2015.
^{(Merged by Junio C Hamano -- gitster -- in commit 152722f, 01 Jun 2015)}

sha1_file: pass empty buffer to index empty file

git add of an empty file with a filter pops complaints from copy_fd about a bad file descriptor.

The comment is laconic:

The clean/smudge interface did not work well when filtering an empty contents (failed and then passed the empty input through).
It can be argued that a filter that produces anything but empty for an empty input is nonsense, but if the user wants to do strange things, then why not?