On 05/25/2010 03:28 AM, Michael J Gruber wrote:
Junio C Hamano venit, vidit, dixit 24.05.2010 03:16:
John<john@xxxxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html