From: Jeff King <peff@peff.net>
To: John <john@puckerupgames.com>
Cc: Nicolas Pitre <nico@fluxnic.net>, git@vger.kernel.org
Subject: Re: serious performance issues with images, audio files, and other "non-code" data
Date: Mon, 24 May 2010 01:39:55 -0400 [thread overview]
Message-ID: <20100524053955.GA4528@coredump.intra.peff.net> (raw)
In-Reply-To: <4BF9C678.6010108@puckerupgames.com>
On Sun, May 23, 2010 at 08:21:12PM -0400, John wrote:
> *.jpg binary -delta
> *.png binary -delta
> *.psd binary -delta
> *.gz binary -delta
> *.bz2 binary -delta
> .. and so on.
>
> [...]
>
> Is there any reason why someone would NOT want the above
> ".gitattributes" defined by default?
I delta jpgs in one of my repositories. It is useful if the exif
metadata changes but the image data does not. I assume you could do the
same with other formats which have compressed and uncompressed portions
(I also do it with video containers). I don't think it would ever make
sense to try to delta gzip'd or bzip'd contents.
I also don't use "binary", as I use a custom diff driver instead (binary
implies "-diff").
As for what should be the default, until now the default has always
been that no gitattributes are defined by default. This is nice because
it's simple to understand; git doesn't care about filenames unless you
tell it to. The downside obviously is that it may not perform optimally
for some unusual workloads without extra configuration.
We could probably do defaults for some common extensions, but I'm not
really sure where such a thing should end up. For example, I consider
*.psd a uselessly obscure extension, as Adobe doesn't write software for
my platform of choice. Not that I mind having it in git, but rather that
we are inevitably going to miss somebody's pet extension, and then we
are right back where we started with them needing to configure, except
now they also have to figure out which extensions have default
attributes.
-Peff
next prev parent reply other threads:[~2010-05-24 5:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-12 18:53 serious performance issues with images, audio files, and other "non-code" data John
2010-05-12 19:15 ` Jakub Narebski
2010-05-14 5:10 ` Jeff King
2010-05-14 12:54 ` John
2010-05-14 17:26 ` Dirk Süsserott
2010-05-17 23:16 ` Jeff King
2010-05-17 23:33 ` Sverre Rabbelier
2010-05-18 19:07 ` Jeff King
2010-05-18 19:10 ` Sverre Rabbelier
2010-05-18 19:27 ` Jeff King
2010-05-18 19:37 ` Nicolas Pitre
2010-05-18 18:50 ` John
2010-05-18 18:54 ` Sverre Rabbelier
2010-05-18 19:19 ` Jeff King
2010-05-18 19:33 ` Nicolas Pitre
2010-05-18 19:41 ` Jeff King
2010-05-18 19:59 ` Nicolas Pitre
2010-05-24 0:21 ` John
2010-05-24 1:16 ` Junio C Hamano
2010-05-24 7:01 ` John
2010-05-25 6:33 ` Jeff King
2010-05-25 7:28 ` Michael J Gruber
2010-05-25 16:12 ` John
2010-05-25 17:18 ` Nicolas Pitre
2010-05-25 17:47 ` John
2010-05-24 5:39 ` Jeff King [this message]
2010-05-24 6:44 ` John
2010-05-24 6:45 ` Jeff King
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=20100524053955.GA4528@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=john@puckerupgames.com \
--cc=nico@fluxnic.net \
/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).