{"push_id":574575273,"size":1,"distinct_size":1,"ref":"refs/heads/issue-87-fixup-logging","head":"26203c3f9d89f70b95d9f6ae5cf4afeadcf471a6","before":"72c23a28401cd20733643c649b89ac07c03311f4","commits":[{"sha":"26203c3f9d89f70b95d9f6ae5cf4afeadcf471a6","author":{"email":"dca51952447d80bd35bf631bc21f06648798b7e0@6a68.net","name":"Jared Hirsch"},"message":"wip - rethinking the logging format slightly\n\nIt really seems unfortunate to cull all the human-readable comment-like\nloglines. The convention I've been working with only allows for a small\nset of log keys, and I was assuming the second arg, if present, would\nonly be { data: <some data> }.\n\nI now think that, error-style, we can have { msg, data }, and in that way,\nwe can capture which function we are talking about (first argument), as\nwell as more context than just a value or the `beforeEnter` type context\nwe get from the first arg.\n\nAdded this { msg } stuff to the readme, but need to take another pass\nat the converted log lines and make sure they are comprehensible.\n\nTo be continued Tuesday.","distinct":true,"url":"https://api.github.com/repos/mozilla/chronicle/commits/26203c3f9d89f70b95d9f6ae5cf4afeadcf471a6"}]}