[PATCH RFC] show: implement "stack" view

[Sean Farley]

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.

> * 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170623/b163e665/attachment.sig>