From: "Torsten Bögershausen" <tboegi@web.de>
To: Jeff King <peff@peff.net>
Cc: Johannes Sixt <j6t@kdbg.org>,
lars.schneider@autodesk.com, git@vger.kernel.org,
gitster@pobox.com, patrick@luehne.de,
Lars Schneider <larsxschneider@gmail.com>
Subject: Re: [PATCH v1] convert: add support for 'encoding' attribute
Date: Sat, 23 Dec 2017 09:08:54 +0100 [thread overview]
Message-ID: <20171223080854.GA30360@tor.lan> (raw)
In-Reply-To: <20171218131249.GB4665@sigill.intra.peff.net>
On Mon, Dec 18, 2017 at 08:12:49AM -0500, Jeff King wrote:
> On Mon, Dec 18, 2017 at 11:13:34AM +0100, Torsten Bögershausen wrote:
>
> > Just to confirm my missing knowledge here:
> > Does this mean, that git-gui and gitk can decode/reencode
> > the content of a file/blob, when the .gitattributes say so ?
>
> That's my impression, yes.
>
> > If yes, would it make sense to enhance the "git diff" instead ?
> > "git diff --encoding" will pick up the commited encoding from
> > .attributes, convert it into UTF-8, and run the diff ?
>
> You can do something like this already:
>
> git config diff.utf16.textconv 'iconv -f utf16 -t utf8'
> echo file diff=utf16 >.gitattributes
>
> I have no objection to teaching it that "encoding" means roughly the
> same thing, which would have two advantages:
>
> - we could do it in-process, which would be much faster
>
> - we could skip the extra config step, which is a blocker for
> server-side diffs on sites like GitHub
>
> I don't think you'd really need "--encoding". This could just be
> triggered by the normal "--textconv" rules (i.e., just treat this "as
> if" the textconv above was configured when we see an encoding
> attribute).
I can probably come up with a patch the next weeks or so.
>
> > We actually could enhance the "git diff" output with a single
> > line saying
> > "Git index-encoding=cp1251"
> > or so, which can be picked up by "git apply".
>
> That extends it beyond what textconv can do (we assume that textconv
> patches are _just_ for human consumption, and can't be applied). And it
> would mean you'd potentially want to trigger it in more places. On the
> other hand, I don't know that we're guaranteed that a round-trip
> between encodings will produce a byte-wise identical result. The nice
> thing about piggy-backing on textconv is that it's already dealt with
> that problem.
>
> -Peff
next prev parent reply other threads:[~2017-12-23 8:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-11 15:50 [PATCH v1] convert: add support for 'encoding' attribute lars.schneider
2017-12-11 18:39 ` Eric Sunshine
2017-12-11 23:47 ` Lars Schneider
2017-12-11 23:58 ` Eric Sunshine
2017-12-12 10:58 ` Lars Schneider
2017-12-11 20:47 ` Johannes Sixt
2017-12-11 23:42 ` Lars Schneider
2017-12-12 0:59 ` Junio C Hamano
2017-12-12 7:15 ` Johannes Sixt
2017-12-12 10:55 ` Lars Schneider
2017-12-12 19:31 ` Junio C Hamano
2017-12-13 17:57 ` Lars Schneider
2017-12-13 18:11 ` Junio C Hamano
2017-12-13 23:02 ` Lars Schneider
2017-12-14 23:01 ` Junio C Hamano
2017-12-12 7:09 ` Johannes Sixt
2017-12-18 10:13 ` Torsten Bögershausen
2017-12-18 13:12 ` Jeff King
2017-12-23 8:08 ` Torsten Bögershausen [this message]
2017-12-29 13:28 ` [PATCH/RFC 0/2] git diff --UTF-8 tboegi
2017-12-29 13:28 ` [PATCH/RFC 1/2] convert_to_git(): checksafe becomes an integer tboegi
2017-12-29 13:28 ` [PATCH/RFC 2/2] git diff: Allow to reencode into UTF-8 tboegi
2018-02-26 17:27 ` [PATCH/RFC 1/1] Auto diff of UTF-16 files in UTF-8 tboegi
2018-02-26 18:43 ` Peter Krefting
2018-02-27 22:39 ` Jeff King
2017-12-18 18:02 ` [PATCH v1] convert: add support for 'encoding' attribute Junio C Hamano
2017-12-18 21:55 ` Johannes Sixt
2017-12-15 9:58 ` Jeff King
2017-12-18 10:54 ` Lars Schneider
2017-12-18 12:59 ` Jeff King
2017-12-17 17:14 ` Torsten Bögershausen
2017-12-28 16:14 ` Lars Schneider
2017-12-29 12:59 ` Torsten Bögershausen
2017-12-29 13:56 ` Lars Schneider
2018-01-03 19:15 ` Junio C Hamano
2018-01-03 20:45 ` Lars Schneider
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=20171223080854.GA30360@tor.lan \
--to=tboegi@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=lars.schneider@autodesk.com \
--cc=larsxschneider@gmail.com \
--cc=patrick@luehne.de \
--cc=peff@peff.net \
/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).