[PATCH] evolution: make troubles appear in default log (issue4686)
pierre-yves.david at ens-lyon.org
Thu Sep 8 16:47:56 EDT 2016
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.
More information about the Mercurial-devel