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

[Kevin Bullock]

> 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.

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