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

Augie Fackler raf at durin42.com
Fri Oct 13 12:07:49 EDT 2017


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.

> That being said, I'm very open to any option that'd make this land, even
> if it requires "hidding" the feature... The tweakdefaults idea sounds
> more interesting than the --verbose one.

I'm fine to land this in tweakdefaults - my (personal) goal is to move
tweakdefaults to on-by-default in early 2018, so maybe that's good enough.

I'm +1 to land this patch as-is (after having reflected on it), but
would also be fine to land it inside tweakdefaults.

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list