[PATCH 2 of 3] changeset: adjust json output to use new/old (BC)

Yuya Nishihara yuya at tcha.org
Sat Apr 16 01:40:04 EDT 2016


On Fri, 15 Apr 2016 13:00:11 -0400, timeless wrote:
> On Fri, Apr 15, 2016 at 12:17 PM, Yuya Nishihara <yuya at tcha.org> wrote:
> > On Wed, 13 Apr 2016 12:14:35 -0500, timeless wrote:  
> >> # HG changeset patch
> >> # User timeless <timeless at mozdev.org>
> >> # Date 1460548060 0
> >> #      Wed Apr 13 11:47:40 2016 +0000
> >> # Node ID 4161598737bc141a062d8fa0d2c90da823e5b6c9
> >> # Parent  57f09cb9c2e69b0e8ef89cd21758722ba7e07ff6
> >> changeset: adjust json output to use new/old (BC)
> >>
> >> The previous json structure was not friendly to strongly structured parsing.  
> >
> > Maybe I'm dumb, but I really can't understand what the "strongly structured
> > parsing" is. Could you elaborate a little more?  
> 
> Basically being able to do : {object}.{well-known-property-name}
> 
> for a in copies:
>    print(a.new.path, a.old.path)

Hmm, it sounds like "I want this structure, so I made hg do that." It varies
what structure is the best for users. The original structure is convenient
to map new path to old path, for example.

  for p in files:
      copies.get(p)

> Upon review "new" is a bad choice since some languages would object.
> I'm actually not sure if this is a path or an abspath, I should re-review.

IIRC, it's a canonical path (slash-separated relative path to repository root),
which is an "abspath" in your sense.

> >> --- a/tests/test-log.t
> >> +++ b/tests/test-log.t
> >> @@ -524,7 +524,7 @@
> >>      "tags": ["tip"],
> >>      "parents": ["2ca5ba7019804f1f597249caddf22a64d34df0ba"],
> >>      "files": ["dir/b", "e"],
> >> -    "copies": {"e": "dir/b"}
> >> +    "copies": [{"new": {"path": "e"}, "old": {"path": "dir/b"}}]  
> >
> > Why are only "copies" wrapped by {"path": ...} ?  
> 
> If we have renames, it should affect that too...

I mean why "files" aren't [{"path": "dir/b"}, {"path": "e"}], and "tags"
aren't [{"name": "tip"}], etc. I don't like these, but they would be more
consistent with the new "copies".


More information about the Mercurial-devel mailing list