> * `hg rebase` must be explicitly enabled. Some users think this means they > shouldn't be using it.
Yeah as someone who is learning Mercurial I agree, usually I/people think that we need extensions when we are doing something which is not normal/general. > * `hg push` pushes all heads by default. Great if you are backing up your > work to a non-publishing repo. Bad if you are trying to land something to > the canonical repo. > * `hg update` and `hg pull -u`'s heuristic based model can result in > surprises > * No easy way to figure out how the current working directory revision > relates to the overall repo/DAG > > Many of us have installed extensions, aliases, etc on our own machines or > have rolled these out to our users to pave over these deficiencies. That > works... where you have control to do that. It doesn't generally work in > open source: people are at the whim of what Mercurial supports out of the > box. > > Many of us also understand the concepts of distributed version control - > what the DAG is, how to interact with it, etc. It is really easy to lose > sight of the fact that most users simply want to get stuff done and they > don't care about the complexities. They will learn the minimum number of > commands required to accomplish what they set out to do. A version control > tool is a barrier to them getting actual work done. They will choose the > mechanism that is simplest and fastest. > > Despite all of Mercurial's current deficiencies in this area, it's worth > noting that I think it's still better off than Git. If the leap from single > to multiple heads is hard, try introducing remote refs, tracking branches, > detached HEAD, the reflog, the staging area, etc. And on top of that add a > convoluted CLI that makes grasping the concepts difficult. Many of the > hardcore MQ users at Mozilla detest Git because it is too complex. Only with > a baptism of fire and likely a lot of hand holding do they warm up to Git. > And - get this - once they learn the power of the DAG, of rebasing and > interactive history editing, they fall in love. They think Mercurial's MQ > model is primitive. Then I show them how to do "Git like" multiple head > development in Mercurial and they're like "oh, this is basically the same > except there aren't the complexities of understanding refs, the staging > area, etc - this is quite nice." > > So, topics. > > I desperately want topics to be a compelling replacement for die hard MQ > users. That means that topics needs to maintain the simplicity of MQ as much > as possible. If people start with a single head repository, topics needs to > be as simple to use as MQ is, even if multiple topics do introduce multiple > heads in the DAG. Yet topics should also provide the features needed by > advanced users - those who fully understand how the DAG works and how to > manipulate changesets within it. > > For the beginning user, Mercurial/topics needs to provide: > > * A mechanism to show all active lines of work (list the topics) (and > possibly how they relate to each other and the underlying repository) > * A mechanism to show the current line of work (and possibly how it related > to the overall repository) > * A mechanism to show/search for unfinished changesets > * A mechanism to provide a human friendly name to a changeset > > I think the existing topics experiment shows a ton of promise in these > areas. And as a bonus, the transition from a beginning topics user (1 > published head, 1 topic) to more advanced scenarios is much better than with > MQ because you don't have to transition to different commands (away from the > q* MQ commands): you simply add more advanced commands like "rebase" and > "merge" to your skills set without having to relearn anything. I also love > how topics "fade away" when changesets become published. That's such an > improvement over having to manually delete things later. Just as long as the > user knows when their topics disappear... > > There are still some areas for improving topics. > > 1) `hg log` still shows *all* changesets in the repository. This is We should limit the output to a certain number and will be better if we have hg log --all to get all changesets. Same in the case of hg tags. I think its better to limit output to a certain number and have an --all flag which is quite common. > 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. > > 2) There are ways to list all topics and to show the "stack" of changesets > relevant to what I'm working on. This is great. We're still lacking a way to > easily list and search "all my in progress work." I think something like > Jordi's `hg wip` alias, Facebook's `hg smartlog` or my proposed `hg > underway` formalization of these in the official distribution would go a > long way to addressing this need. I think this command is also an excellent > place to introduce beginner users to the DAG by rendering its graphical > shape as part of rendering multiple unpublished heads / topics. When people > see a concise view of all in progress work with the DAG shape, they can > start to understand how all the changesets relate to one another and how > commands like "rebase" work. > > 3) `hg topics` isn't showing any changeset metadata, such as the hash > fragment, author, or first N characters of commit message. I like how `hg > topics` is concise. But it is almost too concise. Not showing the author or > commit message means users need to type another command to figure out what's > actually in the topic. Not showing the changeset could mean some power users > wanting to perform advanced operations like grafting a single changeset > could have to perform a 2nd command in order to get the information they > need. > > 4) `hg commit` allows the creation of new, label-less heads (no bookmark, > topic, etc) or the creation of a divergent head on a topic. We should think > long and hard about disallowing this by default in some scenarios (such as > when a repo contains a topic authored by the user). We should also consider > issuing a warning when creating a commit that isn't tracked by any label and > providing a simple command to be printed in that warning that can easily > correct that "mistake." (I vaguely recall discussions about "divergent" > topics at various sprints, but I think it may have revolved around push/pull > behavior?) The goal here is we want to guide beginner users to a single way > of doing feature development. We want simple commands like `hg topic` to > list all their in-progress work. We don't want their commits to fall through > a crack into a "label-less" or "topic-less" world where they need to learn a > new "advanced" command to find them, especially if the "advanced" command > introduces them to more concepts, such as the DAG. We want users to be > introduced to new concepts when they choose to, not when they make a mistake > like failing to attach a topic to a commit. Power users won't like being > forced to use topics. We can have a config flag to disable this. We can also > provide `hg commit --force`. > > 5) `hg topics` feels like it could evolve to do too much. I like `hg stack` > being in its own world. I wonder if we could further separate the querying > pieces of `hg topics` from the manipulation pieces. I think it is important > for commands that make important changes to be isolated from commands that > just query. > > 6) `hg stack` needs some UX love. We could potentially also consolidate > various functionality for "show relevant changesets" into the same command > or suite of commands. Although I'd rather we not have a single command to do > too much or require users to type too many characters or require too many > concepts. In the `hg log` world, I've thought about a "magic log" command > where you could have single character prefixes to "log" as a shortcut to > enabling certain flags. e.g. `hg flog` == `hg log -f`, `hg glog` = `hg log > -G`, `hg gflog` = `hg log -G -f`. Perhaps we could introduce `hg show > <what>` to allow showing pre-defined, concise views of topics, bookmarks, > stack, unfinished work, etc. This would avoid command proliferation while > delimiting query commands from manipulation commands. `hg help show` would > also serve as a gateway to discover other "views" and ways of doing things. > `hg *show` would be reserved for shortcuts like `hg tshow` = `hg show > topics`. Just a thought. > > OK. That's a long post. Hopefully I've given people things to think about. I > want to emphasize topics has a lot of promise and there's a lot to love in > its current implementation. I just hope we can leverage the opportunity to > solve some longstanding shortcomings in the user experience in the process > of implementing it. I hope we can design the experience such that it is > enjoyable for existing MQ users and especially to new users of version > control. If we can provide an experience that is compelling for new users > and provides an effective transition towards advanced features without > alienating power users, that will be a compelling reason to choose Mercurial > over other version control tools. I think topics has that potential more > than branches, bookmarks, and MQ ever did. > > _______________________________________________ > Mercurial-devel mailing list > Mercurial-devel@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel > _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel