git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Joshua Juran <jjuran@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Drew Northup <drew.northup@maine.edu>,
	Git mailing list <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [RFC] Print diffs of UTF-16 to console / patches to email as UTF-8...?
Date: Fri, 22 Oct 2010 15:13:39 -0400	[thread overview]
Message-ID: <20101022191339.GA13581@sigill.intra.peff.net> (raw)
In-Reply-To: <E7645863-A3AD-4EE1-AF6B-71C50A859619@gmail.com>

On Fri, Oct 22, 2010 at 11:28:44AM -0700, Joshua Juran wrote:

> >What's wrong with .gitattributes for this use case?  I would think a
> >clean/smudge filter would produce very good behavior from most git
> >commands.
> 
> I wrote a Mac<->UTF-8 converter in C++ and set it as the clean/smudge
> filter for .r (Rez) files.  Checkouts were noticeably slower (on a
> real machine, not one of my antiques).  This would be much worse if I
> also applied it to C and C++ source files (most, but not all, of
> which are ASCII anyway).

Not surprising, as you were probably running your filter a lot. Clean
and smudge could perhaps benefit from the same notes-caching layer that
textconv uses (caching the "smudged" version of each clean file).

But that would only impact checkout. Most other operations use the
"clean" representation already, so they should be full-speed.

You could also cache the other way (mapping smudged sha1's into clean
sha1's). But I doubt that would do you any good. We generally see those
when updating the index with "git add", which means either the stat
information is clean (and we don't have the clean the file) or it isn't
(in which case you probably have new content that has not been seen
before, which means a cache miss).

And of course it doesn't help the other clean/smudge inconveniences you
ran into.

-Peff

  reply	other threads:[~2010-10-22 19:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-22 16:06 [RFC] Print diffs of UTF-16 to console / patches to email as UTF-8...? Drew Northup
2010-10-22 16:18 ` Jonathan Nieder
2010-10-22 17:01   ` Drew Northup
2010-10-22 17:12     ` Jonathan Nieder
2010-10-22 17:27       ` Drew Northup
2010-10-22 17:30         ` Jonathan Nieder
2010-10-22 17:58           ` Jakub Narebski
2010-10-22 17:48         ` Jakub Narebski
2010-10-22 18:06           ` Drew Northup
2010-10-22 19:18             ` Jakub Narebski
2010-10-22 18:28   ` Joshua Juran
2010-10-22 19:13     ` Jeff King [this message]
2010-10-22 19:53     ` Jonathan Nieder
2010-10-22 20:18       ` Git Attribute: File Text Encoding {WAS: Re: [RFC] Print diffs of UTF-16 to console / patches to email as UTF-8...?} Drew Northup
2010-10-22 21:49         ` Jakub Narebski

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=20101022191339.GA13581@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=drew.northup@maine.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jjuran@gmail.com \
    --cc=jrnieder@gmail.com \
    /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).