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

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri Sep 9 12:38:28 EDT 2016

On 09/09/2016 06:31 PM, Matt Mackall wrote:
> On Wed, 2016-09-07 at 15:23 -0400, Augie Fackler 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?
> Bookmarks and branches did indeed get output added to default log. But no user
> would see that output until they started using those things (one of the reasons
> the "default" branch is invisible). So fragile tooling that couldn't handle them
> appearing wouldn't break simply from upgrading.
> There are two key points to this pattern:
> - no behavior change for repos not using a feature
> - output change is introduced WITH the feature
> This second is essential to ensure that there's no timeframe where users could
> start coding production scripts against the feature and then get broken simply
> by upgrading. Note that it IS ok if using a new feature breaks something (that's
> unavoidable!) but it's NOT ok if simply upgrading does.
> So this boat has already sailed for "troubles", because we've had them for a
> while.

But they have been experimental (with no in-core way to get them) the 
whole time so backward compatibility is not to be expected yet.


Pierre-Yves David

More information about the Mercurial-devel mailing list