[PATCH RFC] show: implement "stack" view

[Sean Farley]

Gregory Szorc <gregory.szorc at gmail.com> writes:

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

I was more getting at how to change the view in a general way. Perhaps
if that existed, then the logic wouldn't need to be duplicated for each
view.

Alternatively, the answer could be that users can't extend / change the
view. Or that power users are offered a revset (e.g. hg log -r show_wip
or something) and can provide their own template.

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

To be honest, it didn't help. I think of 'show' as something that should
take a view name or a revset. I'll probably just end up writing my own
wrapper if need be.
-------------- 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/20170704/156a6bf5/attachment.sig>