[PATCH 11 of 11 V2] filemerge: use 'basic' as the default of '[ui] mergemarkers' for safety

FUJIWARA Katsunori foozy at lares.dti.ne.jp
Mon Jul 7 17:34:42 CDT 2014


At Mon, 7 Jul 2014 16:26:50 +0000,
Durham Goode wrote:
> 
> On 7/5/14, 11:07 AM, "FUJIWARA Katsunori" <foozy at lares.dti.ne.jp> wrote:
> 
> >
> >At Sun, 06 Jul 2014 03:00:10 +0900,
> >FUJIWARA Katsunori wrote:
> >> 
> >> # HG changeset patch
> >> # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> >> # Date 1404583001 -32400
> >> #      Sun Jul 06 02:56:41 2014 +0900
> >> # Node ID f5d064452b9b7fa6c001c5f92baf7ae1c34fd8a0
> >> # Parent  21eb3ac84075d72de5adc097f8fe4bfe1f66c1b8
> >> filemerge: use 'basic' as the default of '[ui] mergemarkers' for safety
> >> 
> >> Before this patch, 'detailed' is used as the default of '[ui]
> >> mergemarkers'. This embeds non-ASCII characters in tags, branches,
> >> bookmarks, author and/or commit descriptions into merged files in the
> >> encoding specified by '--encoding' global option, 'HGENCODING' or
> >> other locale setting environment variables.
> >> 
> >> But, if files to be merged use another encoding, this behavior breaks
> >> consistency of encoding in merged files.
> >> 
> >> For example, ISO-2022-JP or EUC-JP are sometimes used as the file
> >> encoding for Japanese characters, because of historical and/or
> >> environmental reasons, even though UTF-8 or Shift-JIS are ordinarily
> >> used as the terminal encoding.
> >> 
> >> This can't be resolved automatically, because Mercurial doesn't aware
> >> encoding of managed files.
> >> 
> >> This patch uses 'basic' as the default of '[ui] mergemarkers' to avoid
> >> embedding encoding sensitive characters for safety.
> >> 
> >> This patch puts '[ui] mergemarkers = detailed' into default hgrc file
> >> for tests, to reduce changes for tests in this patch.
> >
> >I choose using 'basic' as 'ui.mergemarkers' in default for simplicity
> >in this patch.
> >
> >But is it better to use a simpler template (like "{node|short}", for
> >example) instead of current one for 'ui.mergemarkertemplate' in default ?
> 
> What happens when non-ascii characters are inserted in the file? Does it
> just show garbage? Or does it break stuff?

How merged file appears depends on how editors/viewers detect
encodings of the file.

  - detect by trying to decode whole file in single encoding
    => all non-ascii characters in the file are broken

  - detect by guessing encoding of the first non-ascii character sequence
    => only non-ascii characters in marker lines are broken
       (or vice versa, if marker line appears prior to other non-ascii
       characters)

  - and so on ....


> I don’t think showing just the node is particularly useful, so I don’t
> think that would be a good alternative.  The bookmark and commit messages
> are the most important, but I guess both of those could have the non-ascii
> characters?

At least, we should assume that commit message may use non-ascii
characters (the tweet of the user using non-ascii characters in commit
messages made a start of working for this patch series).

Then, non-ascii characters may not be used in bookmarks, but we
shouldn't assume it, because Mercurial itself allows users to use
non-ascii characters for it: users are more adventurous than our
expectations :-)


> Is there any way we can sanitize the markers to just be ascii
> characters? Or does that introduce more problems?

Would you assume that "sanitize" replaces non-ascii characters by
'0xXX'-like escaping or so ?

Such "sanitize" makes marker texts decrease own readability seriously
(at least, Japanese text does so, if sanitized)


> I’m not familiar enough with encoding issues to think of a good
> alternative here.

IMHO, for safety of novice users who don't know well about encoding
and/or Mercurial, '[ui] mergemarkers' should be 'basic' in default,
even though 'detailed' marker looks rich and good (I think so, too).

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp


More information about the Mercurial-devel mailing list