[PATCH RFC] show: implement "stack" view

[Gregory Szorc]

On Fri, Jun 23, 2017 at 2:24 PM, Sean Farley <sean at farley.io> wrote:

> Gregory Szorc <gregory.szorc at gmail.com> writes:
>
> > # HG changeset patch
> > # User Gregory Szorc <gregory.szorc at gmail.com>
> > # Date 1497726059 21600
> > #      Sat Jun 17 13:00:59 2017 -0600
> > # Node ID c9a3d8cdbb925614419216d6e99d9a70f03d926d
> > # Parent  9fcb6df413c9ca475e705ecc15df07584dadb0c1
> > show: implement "stack" view
> >
> > People often want to know what they are working on *now*. As part of
> > this, they also commonly want to know how that work is related to other
> > changesets in the repo so they can perform common actions like rebase,
> > histedit, and merge.
> >
> > `hg show work` made headway into this space. However, it is geared
> > towards a complete repo view as opposed to just the current line of
> > work. If you have a lot of in-flight work or the repo has many heads,
> > the output can be overwhelming. The closest thing Mercurial has to
> > "show me the current thing I'm working on" that doesn't require custom
> > revsets is `hg qseries`. And this requires MQ, which completely changes
> > workflows and repository behavior and has horrible performance on large
> > repos. But as sub-optimal as MQ is, it does some things right, such as
> > expose a model of the repo that is easy for people to reason about.
> > This simplicity is why I think a lot of people prefer to use MQ, despite
> > its shortcomings.
> >
> > One common development workflow is to author a series of linear
> > changesets, using bookmarks, branches, anonymous heads, or even topics
> > (3rd party extension). I'll call this a "stack." You periodically
> > rewrite history in place (using `hg histedit`) and reparent the stack
> > against newer changesets (using `hg rebase`). This workflow can be
> > difficult because there is no obvious way to quickly see the current
> > "stack" nor its relation to other changesets. Figuring out arguments to
> > `hg rebase` can be difficult and may require highlighting and pasting
> > multiple changeset nodes to construct a command.
> >
> > The goal of this commit is to make stack based workflows simpler
> > by exposing a view of the current stack and its relationship to
> > other releant changesets, notably the parent of the base changeset
> > in the stack and newer heads that the stack could be rebased or merged
> > into.
> >
> > Introduced is the `hg show stack` view. Essentially, it finds all
> > mutable changesets from the working directory revision in both
> > directions, stopping at a merge or branch point. This limits the
> > revisions to a DAG linear range.
> >
> > The stack is rendered as a concise list of changesets. Alongside the
> > stack is a visualization of the DAG, similar to `hg log -G`.
> >
> > Newer public heads from the branch point of the stack are rendered
> > above the stack. The presence of these heads helps people understand
> > the DAG model and the relationship between the stack and changes made
> > since the branch point of that stack. If the "rebase" command is
> > available, a `hg rebase` command is printed for each head so a user
> > can perform a simple copy and paste to perform a rebase.
> >
> > This patch is currently RFC quality. There are several TODOs. Most
> > are documented inline. Notable ones are:
> >
> > * Discuss visualization format. I've gone back and forth on whether to
> >   connect the stack and heads DAGs. I think it looks nicer if they
> >   are disconnected. But I also think disconnecting hurts DAG
> >   comprehension.
>
> I would lean towards displaying the graph so that it's easier to
> visualize when your stack has diverged.
>
> > * Need to use templater (Yuya is refactoring and I didn't want to
> >   introduce conflicts for the templater changes I want to make to
> >   support this)
>
> How will a user customize the template? Will there be place holders? Or
> is it something to override?
>
> For example, I wanted to add remotename info to the output from 'show'
> but debated on how to do that exactly.
>

I fixed `hg show work` a few days ago so it now displays names from all
namespaces. Would need to do something similar for this view.


>
> > * Consider using graphmod or at least consult things like symbol
> >   characters. Using graphmod explicitly would require a lot of new
> >   features in graphmod. I'm not sure it is worth it for a single
> >   consumer.
> >
> > My immediate goal is to hear "+1" on the command and the general
> > visualization.  Then things can be formalized using proper techniques.
> > Remember, `hg show` isn't covered by BC guarantees. So perfect should
> > be the enemy of good.
>
> I ended up having to disable 'show' because I kept typing 'hg show REV'
> too much, for what it's worth.
>

I think you'll appreciate the new commands.show.aliasprefix config option I
added a few days ago. I now regularly use `hg swork` via aliasprefix=s.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170701/f41e96d8/attachment.html>