From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Nguyen Thai Ngoc Duy" <pclouds@gmail.com>,
"Ævar Arnfjörð" <avarab@gmail.com>
Subject: Re: [PATCH 00/22] Refactor to accept NUL in commit messages
Date: Thu, 27 Oct 2011 17:19:05 -0700 [thread overview]
Message-ID: <20111028001905.GA10802@sigill.intra.peff.net> (raw)
In-Reply-To: <7v1utyx9ri.fsf@alter.siamese.dyndns.org>
On Thu, Oct 27, 2011 at 05:03:29PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > My interest is to make things like bare-repository diff (and everything
> > built on it; i.e., things like github, gitweb, or whatever) do the sane
> > thing for these people, even if I think what they're doing is wrong.
>
> I do not think we are talking about right or wrong. I was primarily saying
> that textconv may not be the right thing (think github/gitweb showing blob
> contents, nicely formatted inside the chrome the site provides).
But I think it is probably a wrong thing to store utf-16 as the
canonical format inside the git repository. Git simply can't handle it
for diffing. And the right thing, as you suggested, is clean/smudge.
But I'm dealing with repositories on the server side, where it is too
late to do clean/smudge; I just get whatever junk people commited.
> We have in-repository representation that diff and grep and friends work
> on, and output conversion layer that externalizes the result of them in
> the form of "smudge". Another layer above the in-repository representation
> and below operations could convert UTF-16 to UTF-8 when going outward and
> in the opposite when going inward.
I'm not sure that could sanely be done in a backwards compatible way.
Doing it with just textual diffs is a hack, of course, but at least we
know that the damage is limited, and the diff we generate on top doesn't
care that much about the original sha1s[1]. But should read_object_sha1
learn to convert utf-16 into utf-8? I think madness lies that way, as
we are breaking assumptions about sha1 validity.
-Peff
[1] Actually, the text diff does mention the original and resulting
sha1s, which would now either bear no relation to the diff text, or bear
no relation to what's in the repo. Either way, I think we are creating
something that can't necessarily be applied, which is bad. And is why I
thought of textconv, which is basically the same concept (and has the
same problems).
next prev parent reply other threads:[~2011-10-28 0:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1319277881-4128-1-git-send-email-pclouds@gmail.com>
2011-10-22 19:09 ` [PATCH 00/22] Refactor to accept NUL in commit messages Jeff King
2011-10-23 10:44 ` Robin Rosenberg
2011-10-23 16:09 ` Jeff King
2011-10-22 22:47 ` Junio C Hamano
2011-10-23 1:24 ` Nguyen Thai Ngoc Duy
2011-10-23 5:51 ` Junio C Hamano
2011-10-23 6:37 ` Nguyen Thai Ngoc Duy
2011-10-23 9:46 ` Junio C Hamano
2011-10-23 10:17 ` Nguyen Thai Ngoc Duy
2011-10-23 16:07 ` Jeff King
2011-10-23 20:16 ` Junio C Hamano
2011-10-24 4:40 ` Junio C Hamano
2011-10-24 5:10 ` Nguyen Thai Ngoc Duy
2011-10-24 11:09 ` Štěpán Němec
2011-10-24 22:45 ` Jeff King
2011-10-25 10:16 ` Štěpán Němec
2011-10-25 14:07 ` Junio C Hamano
2011-10-27 18:13 ` Jeff King
2011-10-27 18:47 ` Junio C Hamano
2011-10-27 18:52 ` Jeff King
2011-10-27 19:14 ` Junio C Hamano
2011-10-27 23:44 ` Jeff King
2011-10-28 0:03 ` Junio C Hamano
2011-10-28 0:19 ` Jeff King [this message]
2011-10-28 1:40 ` Miles Bader
2011-10-28 4:07 ` 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=20111028001905.GA10802@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@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).