Re: serious performance issues with images, audio files, and other "non-code" data
- From
- John <john@puckerupgames.com>
- Date
- May 25, 2010, 16:12 UTC
- Message-ID
- <4BFBF701.6060901@puckerupgames.com>
- In-Reply-To
- <4BFB7C24.10609@drmicha.warpmail.net>
On 05/25/2010 03:28 AM, Michael J Gruber wrote:
Show 18 quoted lines
> Junio C Hamano venit, vidit, dixit 24.05.2010 03:16: >> John<john@puckerupgames.com> writes: >> >>> Is there any reason why someone would NOT want the above >>> ".gitattributes" defined by default? >> >> Other than that our originally intended target audience are people who use >> git as a source code control system, not much. >> > > and other than that many people use clean/smudge filters to make git > happily and efficiently deltify compressed file formats (such as gz, > bz2, zip) and still keep compressed checkouts... > > and other than that which you (plural) and I are not thinking of right now. > > Let the defaults be as they are (fit for source control in the proper > sense), it's easy enough to change them for other use cases.
That's fine. We all have different ideas what revision control means. So long as it's clear what git considers "source" and what it considers out of scope, what the defaults are, and what the limitations are, potential users can more fairly evaluate git to see if it fits their needs.
For example, code libraries and shell utilities may not require anything more complicated than line-by-line text-based patches in revision control.
On the other hand, projects such as web sites, mobile phone apps, desktop applications, (and games :) have lots of "source" that is not code. Even XML, which is text-based, but not line-based (and need not contain any newlines), may present a problem for git in this respect.
Perhaps a section in the manual with a header such as "Handling non-text files", or "Revision control for media, XML, and other non line-oriented files" would clear this all up. You could almost cull the body of it from this thread and other similar threads.