From: "Shawn O. Pearce" <spearce@spearce.org>
To: Brian Gernhardt <benji@silverinsanity.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Martin Waitz <tali@admingilde.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Junio C Hamano <junkio@cox.net>,
git@vger.kernel.org
Subject: Re: Unresolved issues
Date: Wed, 21 Feb 2007 12:05:39 -0500 [thread overview]
Message-ID: <20070221170539.GI25559@spearce.org> (raw)
In-Reply-To: <09D527A1-43E2-41A1-AC46-71F64BC409C2@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> wrote:
> It seems to me that a tracked .gitattributes file should have things
> like
>
> *.txt: text
> *.gif: binary
> *.[ch]: text
>
> And the .git/config should have
>
> [attribute "text"]
> mangle = crlf
>
> [attribute "binary"]
> merge = none
>
> The type of each file should be tracked, but what to do with each
> type is a local issue. Trying to merge the two is madness.
Yes, exactly. :-)
I would also recommend that we encourage use of standard MIME types
to define the file types, but don't enforce it. Thus I can setup
something like:
cat >.gitattributes <<EOF
*.txt: text/plain
*.java: text/java-source
*.xml: text/xml
*.bin: mycompany-binary
EOF
cat >>.git/config <<EOF
[attribute "text/*"]
mangle = crlf
[attribute "text/xml"]
merge = better-xml-mergething
[attribute "mycompany-binary"]
mangle = no
merge = mycompany-binarymerge
EOF
And have all three classes of files be mangled with CRLF, but
XML files are also merged with the external merge process, and the
special type mycompany-binary might be a local file format that comes
with its own merge tools, but is not exactly a registered MIME type.
One advantage here is we can setup attribute.text/*.mangle=crlf on
Windows platforms by default for users, as we can reasonably assume
all text content falls into this MIME type...
--
Shawn.
next prev parent reply other threads:[~2007-02-21 17:05 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-20 7:28 Unresolved issues Junio C Hamano
[not found] ` <Pine.LNX.4.64.07022009 34270.20368@woody.linux-foundation.org>
2007-02-20 8:57 ` Andy Parkins
2007-02-20 20:10 ` [PATCH] Use git-update-ref to update a ref during commit in git-cvsserver Andy Parkins
2007-02-20 21:57 ` Nicolas Pitre
2007-02-21 5:54 ` Junio C Hamano
2007-02-21 9:08 ` Andy Parkins
2007-02-27 12:48 ` [PATCH 1/2] Make 'cvs ci' lockless in git-cvsserver by using git-update-ref Andy Parkins
2007-02-27 13:55 ` Jakub Narebski
2007-02-27 14:35 ` Nicolas Pitre
2007-02-27 23:44 ` Junio C Hamano
2007-02-28 8:44 ` Andy Parkins
2007-02-28 18:06 ` Junio C Hamano
2007-02-27 12:49 ` [PATCH 2/2] cvsserver: Remove trailing "\n" from commithash in checkin function Andy Parkins
2007-02-27 23:45 ` Junio C Hamano
2007-02-28 8:45 ` Andy Parkins
2007-02-27 23:37 ` [PATCH] Use git-update-ref to update a ref during commit in git-cvsserver Martin Langhoff
2007-02-20 17:41 ` Unresolved issues Linus Torvalds
2007-02-20 21:43 ` Junio C Hamano
2007-02-21 0:21 ` Linus Torvalds
2007-02-21 0:25 ` Junio C Hamano
2007-02-21 0:39 ` Johannes Schindelin
2007-02-21 0:56 ` Linus Torvalds
2007-02-21 0:51 ` David Lang
2007-02-21 1:12 ` Johannes Schindelin
2007-02-21 1:51 ` Nicolas Pitre
2007-02-21 2:03 ` Linus Torvalds
2007-02-21 16:32 ` Robin Rosenberg
2007-02-21 1:49 ` Theodore Tso
2007-02-21 10:42 ` Martin Waitz
2007-02-21 12:55 ` Johannes Schindelin
2007-02-21 16:57 ` Brian Gernhardt
2007-02-21 17:05 ` Shawn O. Pearce [this message]
2007-02-22 8:28 ` [PATCH] git-status: do not be totally useless in a read-only repository Junio C Hamano
2007-02-22 8:30 ` [PATCH] update-index: do not die too early " Junio C Hamano
2007-02-26 1:33 ` Unresolved issues Julian Phillips
2007-02-26 3:39 ` Junio C Hamano
2007-02-26 5:10 ` Julian Phillips
2007-02-26 5:33 ` Junio C Hamano
2007-02-27 20:10 ` Johannes Schindelin
-- strict thread matches above, loose matches on Subject: below --
2008-03-18 1:12 Junio C Hamano
2008-03-18 1:26 ` Jeff King
2008-03-18 1:56 ` Linus Torvalds
2008-03-19 22:48 ` Sam Vilain
2008-04-19 8:19 Junio C Hamano
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=20070221170539.GI25559@spearce.org \
--to=spearce@spearce.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=benji@silverinsanity.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=tali@admingilde.org \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.