[PATCH v2] transaction-summary: show the range of new revisions upon pull/unbundle (BC)

[Augie Fackler]

> On Oct 13, 2017, at 12:24, Kevin Bullock <kbullock+mercurial at ringworld.org> wrote:
> 
>> On Oct 13, 2017, at 11:07, Augie Fackler <raf at durin42.com> wrote:
>> 
>> On Fri, Oct 13, 2017 at 09:10:52AM +0200, Denis Laxalde wrote:
>>> Kevin Bullock a écrit :
>>>>> On Oct 12, 2017, at 03:13, Denis Laxalde <denis at laxalde.org> wrote:
>>>>> 
>>>>> # HG changeset patch
>>>>> # User Denis Laxalde <denis.laxalde at logilab.fr>
>>>>> # Date 1507793990 -7200
>>>>> #      Thu Oct 12 09:39:50 2017 +0200
>>>>> # Node ID 48cca33a1b611c82a2bd72a2f72b80f321604f42
>>>>> # Parent  f1c2552c2de78a2f8a0c0ded099ccb200aad27d0
>>>>> # Available At http://hg.logilab.org/users/dlaxalde/hg
>>>>> #              hg pull http://hg.logilab.org/users/dlaxalde/hg -r 48cca33a1b61
>>>>> # EXP-Topic pull-info-transaction
>>>>> transaction-summary: show the range of new revisions upon pull/unbundle (BC)
>>>>> 
>>>>> Upon pull or unbundle, we display a message with the range of new revisions
>>>>> fetched. This revision range could readily be used after a pull to look out
>>>>> what's new with 'hg log'. The algorithm takes care of filtering "obsolete"
>>>>> revisions that might be present in transaction's "changes" but should not be
>>>>> displayed to the end user.
>>>> 
>>>> I like the idea, but it feels like it should be behind a config option (which we can enable with ui.tweakdefaults) and/or -v/--verbose output. Same thing we did when adding merge/rebase/etc. info to `hg status --verbose`.
>>>> 
>>> 
>>> I don't quite understand why we'd want to hide this to the end user by
>>> default. If this is about UI, there are already other pieces of
>>> information that would be better for a --verbose output (e.g. the
>>> "adding changesets/manifests/file changes" or "added X changesets with Y
>>> changes to Z files"). Or is this about backwards compatibility?
>> 
>> I think Kevin is worried about BC here, but I know we've added at
>> least obsolete marker information in the past and it's been
>> okay. Probably the best thing to do where would be to make this
>> templated, so that in the future we can make it configurable to a
>> user's (or company's) preferences.
> 
> Correct, I was looking for precedent on how we've handled added output like this. I don't feel strongly about it though -- I doubt many scripts are actually parsing the output of pull. Making it templated is an interesting option but I don't think it blocks landing this.

Per follow-up on IRC, I've queued this patch. Please feel *strongly* encouraged to make the post-pull summary templated!

> 
> pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
> Kevin R. Bullock
>