Re: Should the --encoding argument to log/show commands make any guarantees about their output?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> * just make this more clear in the docs and/or
> * should we adjust the behavior of --encoding or
> * should we do something entirely different, like adding a new command line
> option or
The general spirit is to keep things backwards compatible, so that users which
expect the "raw" (and possible corrupted UTF-8) data still get the same results,
when they updata their Git installation.

A new command line option will allow users to get clean UTF-8.

One suggestion could be
--fixbroken=ISO-8859-1    (a)
--fixbroken=octalescape   (b)
--fixbroken=hexescape     (c)

(a) would replace  "0xf6" with "0xc3 0xb6"
(b) could write "\366"
(c) could write "<F6>"

The exact form of the syntax can be discussed of course.

However, I would probably start with (a), and add other options
if needed.

> * should we just leave things as they are?
.... not the ideal thing.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]