Gregory Szorc <gregory.sz...@gmail.com> writes: > On Fri, Jun 23, 2017 at 2:24 PM, Sean Farley <s...@farley.io> wrote: > >> Gregory Szorc <gregory.sz...@gmail.com> writes: >> >> > # HG changeset patch >> > # User Gregory Szorc <gregory.sz...@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.
signature.asc
Description: PGP signature
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel