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