Re: serious performance issues with images, audio files, and other "non-code" data

[John <john@puckerupgames.com>]

On 05/25/2010 03:28 AM, Michael J Gruber wrote:
> 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.