utils: GroupableOrderedDict.__repr__()

[kaplun]

utils: GroupableOrderedDict.__repr__()

* FIX Implements GroupableOrderedDict.__repr__()
  allowing for having
  >>> assert eval(repr(god)) == god
  (closes #162)

Signed-off-by: Samuele Kaplun <samuele.kaplun@cern.ch>

[jirikuncar]

@kaplun please format the commit message so it is well rendered in release notes. You can check the result by running kwalitee prepare release v1.2.1.. (and try to render the rst).

[kaplun]

What about this?

[jirikuncar]

• Try to use maximal possible length of line before breaking at 72 chars;
• Finish sentences with a dot (.);
• Do not use verbs in commit message titles;
• More information can be found on http://invenio.readthedocs.io/en/latest/technology/git.html#r2-remarks-on-commit-log-messages

[kaplun]

:boom:

[jirikuncar]

@kaplun is there any particular reason why (closes #162) in on new line?

[kaplun]

@jirikuncar is there a particular reason why you are asking it? Would that really make a sensible difference?

The reason is that in the last 5 years we were putting it always on new line.

Anyway, PR is about to be refreshed with the correct newlines.

[tiborsimko]

The reason is that in the last 5 years we were putting it always on new line.

It's only cosmetics, but it's not so clear cut as you put it -- e.g. see the invenio repository history that suggests that it is actually the other style that prevails:

$ git log | grep -c '(closes #[0-9][0-9]'
849
$ git log | grep -c '^      (closes #[0-9][0-9]'
332
$ git log | grep -c '(addresses #[0-9][0-9]'
322
$ git log | grep -c '^      (addresses #[0-9][0-9]'
114

(not even counting the situation where the directive ends up on the next line "naturally indented")

FWIW I personally use Emacs git commit mode and fill-paragraph that takes care of new lines automatically.