On March 12, 2022 1:07 PM, Sean MacLennan wrote: >We have a git repo that is a mirror of an svn repo. The tools create a huge >.gitattribute file that is about 83,000 entries. Almost all are of the form: <path> - >text > >This file kills git grep. A grep that takes <1s without the file takes almost 2 minutes >with the file. So git grep it unusable. > >My current solution is to rename the file: > >-#define GITATTRIBUTES_FILE ".gitattributes" >+#define GITATTRIBUTES_FILE ".gitattributes-no" > >But I would like a cleaner solution so I don't have to maintain my own git. > >My request is more for what would be the best gitish way to solve this; I am willing >to do the actual patch. > >This needs to be something in the local config and not global. My current thoughts >are: > >1) A way to override the default name (much like I do now): > gitattributesfile = .gitattributes-no > >2) A flag variable: > gitattributes = ignore > or > ignoreattributes = true > >I personally like 1) because it would also work for the case where you want to >override a bad .gitattributes file (that you have no control >over) with a good .gitattributes file. I just think it would be more generally useful. > >But I would like to pick a solution that is most likely to get accepted. These may seem a little off the wall, but: 1. Could you use a clean/smudge approach to mess with your bad .gitattributes file before it gets put down on disk? I realize that registering the filter might not be possible given that you need to muck with .gitattributes to do it, but if you have any control at all and can get the filter in, perhaps that might be a way to clean up the bad .gitattributes file. 2. What about a post-checkout hook that fixes .gitattributes and then does an update-index --assume-unchanged on it. This is under the assumption that you will never change .gitattributes in your clone. My $0.02, --Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400) NonStop(211288444200000000) -- In real life, I talk too much.