[PATCH] evolution: make troubles appear in default log (issue4686)

[Pierre-Yves David]

On 09/07/2016 09:39 PM, Kevin Bullock wrote:
>> On Sep 7, 2016, at 14:23, Augie Fackler <raf at durin42.com> wrote:
>>
>> On Fri, Sep 02, 2016 at 10:26:22AM -0500, Kevin Bullock wrote:
>>>> On Sep 2, 2016, at 04:38, liscju <piotr.listkiewicz at gmail.com> wrote:
>>>>
>>>> # HG changeset patch
>>>> # User liscju <piotr.listkiewicz at gmail.com>
>>>> # Date 1472809041 -7200
>>>> #      Fri Sep 02 11:37:21 2016 +0200
>>>> # Node ID 463b164126a0db3f7147787ace34f74deeccc03f
>>>> # Parent  f148bfa40489269be2e48046734f81065129847a
>>>> evolution: make troubles appear in default log (issue4686)
>>>>
>>>> This patch is request for comment, it does not update failing
>>>> test due to new information about troubles, it adds one test
>>>> to show how troubles looks like in default log.
>>>
>>> I think having a way to show troubled changesets as such in the log is a good idea, but the best we're able to do here is to add a new built-in template (cf. `hg log -T phases`). The default log output is very strongly a part of our command-line API, and changing it (even additively!) is a no-no.
>>
>> There's caselaw for adding new lines to the -Tdefault output
>> (bookmarks come to mind), so I think we can probably do that?
>
> Why didn't we do it for phases then?

If I remember correctly (that was 5 year ago), we did not did it for 
phases because that would have affected pretty much every (well, most) 
`hg log` output in the wild without any change in user actions. As every 
new changesets are draft by default, `hg log` for normal user work-flow 
would have started displaying this new information, possibly confusing 
people (and maybe script?). I also suspect that Matt decision was also 
driven by the low importance of phases back then (still somewhat true)

We changed the output for bookmark because people have to opt in to 
bookmarks. People who never changed their work-flow and usage did not 
touched bookmark and did not got their output changed.

The same logic could be applied to evolution's trouble. People/work-flow 
who don't use anything related to evolution will not encounter 
evolution-troubles and will keep their log output unchanged . People who 
venture into new territory will get related information in their log.

To summarize, we did not changed output for phase because (1) it would 
affect all users (2) it would affect many commits. Neither of this 
applies to evolution-troubles, so we should probably include then in the 
default log output. This would be a great help for users encountering 
evolution troubles for the first time.

On the implementation side, the best way to introduce them might be 
through the namespace API.

Cheers

-- 
Pierre-Yves David