5

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.

Jake88
  • 884
  • 1
  • 20
  • 33
  • 1
    The fun part is, when I do it here, the empty file is added anyway; if you're willing, you can just ignore the message The patch does work. It looks like the mail just fell off the radar. – jthill May 14 '15 at 02:52
  • That's too bad that they never added it to the core git code. My team is not interesting in compiling and maintaining patches to it's own fork of git (the benefits from the maintenance in this case do not outweigh the cost. If you think about it though, users shouldn't really be submitting empty files into source control. – Jake88 May 14 '15 at 13:07
  • The right fix for this is queued for merge to I think git 2.4.2. – jthill May 19 '15 at 23:34
  • It is still broken here with version 2.4.2. ._. – Feuermurmel May 29 '15 at 11:37
  • @Feuermurmel Yah, it's f6a1e1e, still in pu. – jthill Jun 02 '15 at 03:12
  • @jthill I just posted, before realizing you were the author of the fix. It has been merged on master. – VonC Jun 07 '15 at 18:28
  • @VonC Yah, there's a better comment on the commit itself :-) - - - but the fix is barely even a one-liner, so . . . . . . p.s. nice job on the formatting, there (plus, completeness). – jthill Jun 07 '15 at 19:17
  • @jthill for referencing the commit, I have developed `seec` (https://github.com/VonC/seec). Type `seec f6a1e1e288d13472f5f7fe2b907bb8c0bd69a018`, and it will copy directly in your clipboard (Linux or Windows or Mac) the markdown code representing the merged commit and its parent author. – VonC Jun 07 '15 at 20:02
  • @VonC Oh, you kind person. Thanks! – jthill Jun 07 '15 at 20:24
  • @jthill `seec` (for "see commit"): now with more "`Helped-by:`" (as in `seec 324a9f41cbf96ad994efc3b20be239116eba0dae` and [this answer](http://stackoverflow.com/a/30699239/6309)), and more "`Test-adapted-from:`" (as in `seec 777e75b60568b613e452ebbb30a1fb27c4fd7d8a`, and [this answer](http://stackoverflow.com/a/30696906/6309)) – VonC Jun 07 '15 at 22:46

1 Answers1

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?

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283