D6183: copies: add config option for writing copy metadata to file and/or changset

martinvonz (Martin von Zweigbergk) phabricator at mercurial-scm.org
Tue Apr 16 12:10:13 EDT 2019


martinvonz added a comment.


  In https://phab.mercurial-scm.org/D6183#90738, @yuja wrote:
  
  > >   > >   >  extras field. Almost all extras data are texts, and IIRC we regret that
  > >   > >   >  transplant sources are stored in binary form.
  > >   > >   
  > >   > >   Why not? I picked \0 and \n because they won't appear in filenames, so it's convenient in that way.
  > >   >
  > >   > I don't remember, but we do store even boolean value as text, not in binary
  > >   >  `\0`/`\1` form. `transplant_source` is the solo exception.
  > >   
  > >   
  > >   Perhaps it's just so `{extras}` doesn't print ANSI escape codes and such? (I assume that can still happen if put escape characters in your filenames, for example.)
  >
  > Ok. That might be the reason, and I'm fine with the `\0` separator.
  >
  > >   > https://www.mercurial-scm.org/wiki/ChangesetExtra
  > >   > 
  > >   > And if we pick \0/\n separators, _string_escape() wouldn't be needed
  > >   >  at the encodecopies() layer.
  > >   
  > >   Oh, now I see what you're saying! That's embarrassing. So maybe we should `_string_escape()` the whole thing? I'll do that.
  >
  > Not really. I meant `_string_escape()` could be removed entirely if we store
  >  copies in binary (valid_filename + invalid_filename_separator) form. The extra
  >  dict will be encoded later.
  
  
  Sure, if we're okay with the `\0` and `\n` separators being printed to the terminal when the user uses the `{extras}` template, then we can just drop the encoding. Sounds like you're okay with that, and I also don't care too much, so I'll drop the encoding.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6183

To: martinvonz, #hg-reviewers
Cc: yuja, pulkit, gracinet, marmoute, mercurial-devel


More information about the Mercurial-devel mailing list