> On Oct 10, 2016, at 10:51, Denis Laxalde <denis.laxa...@logilab.fr> wrote: > > Gregory Szorc a écrit : >> There are still some areas for improving topics. >> >> 1) `hg log` still shows *all* changesets in the repository. This is >> confusing for users that don't want to be burdened with the complexity >> of multiple heads. I'd like the behavior of `hg log` to only show >> ancestors - and possibly descendants - of the working directory >> changeset when the working directory changeset is unpublished and has a >> topic. If we show descendants, we should delimit the current changeset >> somehow, possibly by making -G or a mode like it the default in this >> scenario. Realistically, I think `hg log` should behave like `hg log -f` >> and `hg log --children` should supplement that with descendants and a >> marking of the wdir changeset. If there is a branch point in the >> descendants, we should automatically add the graphical view because >> showing changesets from multiple DAG heads without the graphical view is >> really confusing. I can also make the argument that the graphical view >> should always be shown so merge commits can be rendered properly. > > It seems to me that, if we consider topics as lightweight *branches*, we > can improve (part of) this : > > * when on a topic, `hg log` could only show changesets in the current > topic (and their public ancestors); > > * when not on a topic, a bare `hg log` could only show changesets > without a topic; > > * with an additional -t/--topic option to log command, we could see > changesets of a particular topic even we not activated.
Per discussion on Sunday, we decided to introduce "hg display <view>" as a new mechanism that essentially is a named (revset, template) pair to show useful views of repository data (not necessarily limited to changeset data). We'll prefer to use "hg display" for common queries instead of adding yet more functionality and special behavior to "hg log." I'll hopefully send out an RFC series soon that explains "hg display" in more detail. > > Basically, just like with named branches, I think. > > > If we follow the same idea (topics are branches), why not considering > make `hg pull` behave differently with topics? > > I would imagine that `hg pull` will not fetch any changeset with a > topic unless the client is on a topic that got updated remotely. But, > the server response could list information about available topics, > something like: > > remote: new topics "bugfix1", "newfeature22" > remote: new changes in topics "foo" > remote: topics "importbugfix", "docstringtypo" got published > > And add a -t/--topic option to `hg pull` to explicitly pull some topic(s). > > Here, this diverges from `hg pull` behavior with respect to named > branches (all branches are pulled by default). But this might be an > occasion to "fix" things? > > -- > Denis Laxalde > Logilab http://www.logilab.fr _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
