git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <rsbecker@nexbridge.com>
To: "'Sean MacLennan'" <seanm@seanm.ca>, <git@vger.kernel.org>
Subject: RE: Request: a way to ignore .gitattributes
Date: Sat, 12 Mar 2022 16:13:26 -0500	[thread overview]
Message-ID: <01ab01d83656$071d7cd0$15587670$@nexbridge.com> (raw)
In-Reply-To: <20220312130712.6d9d2d00@zonker.seanm.ca>

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.




  reply	other threads:[~2022-03-12 21:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-12 18:07 Request: a way to ignore .gitattributes Sean MacLennan
2022-03-12 21:13 ` rsbecker [this message]
2022-03-12 23:50   ` Junio C Hamano
2022-03-13 16:19   ` Sean MacLennan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='01ab01d83656$071d7cd0$15587670$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=git@vger.kernel.org \
    --cc=seanm@seanm.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).