git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 00/22] Refactor to accept NUL in commit messages

From
Jeff King <peff@peff.net>
Date
Oct 28, 2011, 00:19 UTC
Message-ID
<20111028001905.GA10802@sigill.intra.peff.net>
In-Reply-To
<7v1utyx9ri.fsf@alter.siamese.dyndns.org>
On Thu, Oct 27, 2011 at 05:03:29PM -0700, Junio C Hamano wrote:
Show 9 quoted lines
> 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.

Show 5 quoted lines
> 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).

Previous: Junio C HamanoNext: Miles Bader
Message 24 of 26 in “Re: [PATCH 00/22] Refactor to accept NUL in commit messages”
  1. Jeff KingOct 22, 2011
  2. Robin RosenbergOct 23, 2011
  3. Jeff KingOct 23, 2011
  4. Junio C HamanoOct 22, 2011
  5. Nguyen Thai Ngoc DuyOct 23, 2011
  6. Junio C HamanoOct 23, 2011
  7. Nguyen Thai Ngoc DuyOct 23, 2011
  8. Junio C HamanoOct 23, 2011
  9. Nguyen Thai Ngoc DuyOct 23, 2011
  10. Jeff KingOct 23, 2011
  11. Junio C HamanoOct 23, 2011
  12. Junio C HamanoOct 24, 2011
  13. Nguyen Thai Ngoc DuyOct 24, 2011
  14. Štěpán NěmecOct 24, 2011
  15. Jeff KingOct 24, 2011
  16. Štěpán NěmecOct 25, 2011
  17. Junio C HamanoOct 25, 2011
  18. Jeff KingOct 27, 2011
  19. Junio C HamanoOct 27, 2011
  20. Jeff KingOct 27, 2011
  21. Junio C HamanoOct 27, 2011
  22. Jeff KingOct 27, 2011
  23. Junio C HamanoOct 28, 2011
  24. Jeff KingOct 28, 2011
  25. Miles BaderOct 28, 2011
  26. Junio C HamanoOct 28, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.