Re: [PATCH 2 of 2] commands: introduce `hg display`

[Gregory Szorc]

On Thu, Nov 10, 2016 at 9:44 AM, Pierre-Yves David <
pierre-yves.da...@ens-lyon.org> wrote:

>
>
> On 11/08/2016 03:50 AM, Gregory Szorc wrote:
>
>> On Mon, Nov 7, 2016 at 4:41 AM, Pierre-Yves David
>> >
>> wrote:
>>
>> On 11/05/2016 07:26 PM, Gregory Szorc wrote:
>>
>> # HG changeset patch
>> # User Gregory Szorc > >
>> # Date 1478370119 25200
>> #  Sat Nov 05 11:21:59 2016 -0700
>> # Node ID 0ebc1e627383bdf017f509a60725c0b39d6d40d9
>> # Parent  4bce42e7330311b58ecd38a4acbcd2d2dd1351ba
>> commands: introduce `hg display`
>>
>>
>> I've not looked into this in details yet¹, but is looks like it
>> should be flagged (EXPERIMENTAL) and having some plan page could be
>> useful.
>>
>>
>> I'm fine marking it as experimental. How do you want that done?
>>
>
> As for everything else, having "(EXPERIMENTAL)" on the first line should
> do it.
>
> Regarding the plan page, this proposed command was discussed and had
>> buy-in at the 4.0 Sprint. I believe the commit message captures most of
>> the important details of that discussion.
>>
> >
>
>> I'm not sure what benefit a wiki page will provide. If it is capturing
>> planned display views, I can list those here:
>>
>> * Things we have read-only commands for today (tags, branches,
>> bookmarks, possibly qseries)
>> * inprogress/smartlog/wip/unfinished (whatever we call it)
>> * stack
>> * Anything else people think of
>>
>
> You certainly have buy in the the general idea, I expect many details to
> be ironed out. A wiki page will allow us to discuss and track many of them:
>
> - Possible targets,
> - Possible output,
> - backward compatibility story,
> - progress tracking,
> - name discussion (because apparently some people have idea)
> - etc,
>
> Cheers and extra thank for tackling this,
>

https://www.mercurial-scm.org/wiki/DisplayCommandPlan now exists.

What are the next plans for this series? I'd *really* like to get something
landed because I feel it could benefit from us developers using it during
the 4.1 cycle. This feature is not something I feel comfortable landing
towards the end of a cycle and then shipping: it needs time to bake.

Perhaps we could take a laissez faire attitude and let it exist in @
enabled by default and make a shipping decision towards the end of the
release cycle?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2] commands: introduce `hg display`

[Pierre-Yves David]

On 11/08/2016 03:50 AM, Gregory Szorc wrote:

On Mon, Nov 7, 2016 at 4:41 AM, Pierre-Yves David
>
wrote:

On 11/05/2016 07:26 PM, Gregory Szorc wrote:

# HG changeset patch
# User Gregory Szorc >
# Date 1478370119 25200
#  Sat Nov 05 11:21:59 2016 -0700
# Node ID 0ebc1e627383bdf017f509a60725c0b39d6d40d9
# Parent  4bce42e7330311b58ecd38a4acbcd2d2dd1351ba
commands: introduce `hg display`


I've not looked into this in details yet¹, but is looks like it
should be flagged (EXPERIMENTAL) and having some plan page could be
useful.


I'm fine marking it as experimental. How do you want that done?


As for everything else, having "(EXPERIMENTAL)" on the first line should 
do it.



Regarding the plan page, this proposed command was discussed and had
buy-in at the 4.0 Sprint. I believe the commit message captures most of
the important details of that discussion.

>

I'm not sure what benefit a wiki page will provide. If it is capturing
planned display views, I can list those here:

* Things we have read-only commands for today (tags, branches,
bookmarks, possibly qseries)
* inprogress/smartlog/wip/unfinished (whatever we call it)
* stack
* Anything else people think of


You certainly have buy in the the general idea, I expect many details to 
be ironed out. A wiki page will allow us to discuss and track many of them:


- Possible targets,
- Possible output,
- backward compatibility story,
- progress tracking,
- name discussion (because apparently some people have idea)
- etc,

Cheers and extra thank for tackling this,

--
Pierre-Yves David
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2] commands: introduce `hg display`

[Gregory Szorc]

On Mon, Nov 7, 2016 at 2:03 AM, Denis Laxalde 
wrote:

> Gregory Szorc a écrit :
>
>> For the command name, we would have preferred `hg show` because it is
>> shorter and not ambigious with any other core command. However, a
>> number of people have created `hg show` as effectively an alias to
>> `hg export`. And, some were concerned that Git users used to `git show`
>> being equivalent to `hg export` would be confused by a `hg show` doing
>> something different.
>>
>
> `git show` is not equivalent to `hg export`, quoting git-show(1):
>
>Shows one or more objects (blobs, trees, tags and commits).
>
>For commits it shows the log message and textual diff. It also
>presents the merge commit in a special format as produced by git
>diff-tree --cc.
>
>For tags, it shows the tag message and the referenced objects.
>
>For trees, it shows the names (equivalent to git ls-tree with
>--name-only).
>
>For plain blobs, it shows the plain contents.
>

TIL. I've only ever used `git show` for the "show a commit representation"
use case and `git cat-file` for displaying low-level objects.


>
> So only the first case is equivalent to `hg export` (or probably more
> `hg log -vpr`). Other cases are quite close to the "view" concept
> introduced here, as far as I understand.
>
> Then if a revision can be registered as a view, `hg show` could just be
> a plain replacement to the aforementioned alias I guess.
>
> Given this and the conflict with `hg diff`, could we reconsider
> the command name?
>

That is an interesting proposal. But I'm concerned with overlapping
namespaces. What values do we allow for the non-view behavior? Hash
fragments? Names (bookmarks, branches, tags)? If we allow names, what
happens when a name in a repo conflicts with a registered view name? What
happens if a view name conflicts with a changeset prefix? Of course, to
know if there is a collision you have to load names. That means (slightly
more) overhead to run the command.

FWIW, my idea for this command was to show representations of multiple
things. I'm willing to entertain the idea of "show me single entity X"
(changeset, tag, bookmark, etc). The easy solution is an argument to a view
(`hg display tag my-tag`). Things get harder when we merge namespaces.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2] commands: introduce `hg display`

[Gregory Szorc]

On Sun, Nov 6, 2016 at 1:52 AM, timeless  wrote:

> Gregory Szorc wrote:
> > @@ -2019,6 +2026,13 @@ Dish up an empty repo; serve it cold.
> >diff repository (or selected files)
> >
> >
> > +  
> > +  display
> > +  
> > +  
> > +  show various repository information
> > +  
> > +  
> >
> >export
> >
>
> Will /help/display list the views it supports?
>

It should. I forgot to implement that. It can be done as a follow-up easily
enough.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2] commands: introduce `hg display`

[Denis Laxalde]

Gregory Szorc a écrit :

For the command name, we would have preferred `hg show` because it is
shorter and not ambigious with any other core command. However, a
number of people have created `hg show` as effectively an alias to
`hg export`. And, some were concerned that Git users used to `git show`
being equivalent to `hg export` would be confused by a `hg show` doing
something different.


`git show` is not equivalent to `hg export`, quoting git-show(1):

   Shows one or more objects (blobs, trees, tags and commits).

   For commits it shows the log message and textual diff. It also
   presents the merge commit in a special format as produced by git
   diff-tree --cc.

   For tags, it shows the tag message and the referenced objects.

   For trees, it shows the names (equivalent to git ls-tree with
   --name-only).

   For plain blobs, it shows the plain contents.

So only the first case is equivalent to `hg export` (or probably more
`hg log -vpr`). Other cases are quite close to the "view" concept
introduced here, as far as I understand.

Then if a revision can be registered as a view, `hg show` could just be
a plain replacement to the aforementioned alias I guess.

Given this and the conflict with `hg diff`, could we reconsider
the command name?


--
Denis Laxalde
Logilab http://www.logilab.fr
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2] commands: introduce `hg display`

[timeless]

Gregory Szorc wrote:
> @@ -2019,6 +2026,13 @@ Dish up an empty repo; serve it cold.
>diff repository (or selected files)
>
>
> +  
> +  display
> +  
> +  
> +  show various repository information
> +  
> +  
>
>export
>

Will /help/display list the views it supports?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 2] commands: introduce `hg display`

[Gregory Szorc]

# HG changeset patch
# User Gregory Szorc 
# Date 1478370119 25200
#  Sat Nov 05 11:21:59 2016 -0700
# Node ID 0ebc1e627383bdf017f509a60725c0b39d6d40d9
# Parent  4bce42e7330311b58ecd38a4acbcd2d2dd1351ba
commands: introduce `hg display`

Currently, Mercurial has a number of commands to show information. And,
there are features coming down the pipe that will introduce more
commands for showing information.

Currently, when introducing a new class of data or a view that we
wish to expose to the user, the strategy is to introduce a new command
or overload an existing command, sometimes both. For example, there is
a desire to formalize the wip/smartlog/underway/mine functionality that
many have devised. There is also a desire to introduce a "topics"
concept. In the current model, we'd need a new command for
wip/smartlog/etc (that behaves a lot like a pre-defined alias of `hg
log`). For topics, we'd likely overload `hg topic[s]` to both display
and manipulate topics.

Adding new commands for every pre-defined query doesn't scale well
and pollutes `hg help`. Overloading commands to perform read-only and
write operations is arguably an UX anti-pattern: while having all
functionality for a given concept in one command is nice, having a
single command doing multiple discrete operations is not. Furthermore,
a user may be surprised that a command they thought was read-only
actually changes something.

We discussed this at the Mercurial 4.0 Sprint in Paris and decided that
having a single command where we could hang pre-defined views of
various data would be a good idea. Having such a command would:

* Help prevent an explosion of new query-related commands
* Create a clear separation between read and write operations
  (mitigates footguns)
* Avoids overloading the meaning of commands that manipulate data
  (bookmark, tag, branch, etc) (while we can't take away the
  existing behavior for BC reasons, we now won't introduce this
  behavior on new commands)
* Allows users to discover informational views more easily by
  aggregating them in a single location
* Lowers the barrier to creating the new views (since the barrier
  to creating a top-level command is relatively high)

So, this commit introduces the `hg display` command. This command
accepts a positional argument of the "view" to show. New views
can be registered with a decorator. To prove it works, we implement
the "bookmarks" view, which shows a table of bookmarks and their
associated nodes.

We introduce a new style to hold everything used by `hg display`.

For our initial bookmarks view, the output varies from `hg bookmarks`:

* Padding is performed in the template itself as opposed to Python
* Revision integers are not shown
* shortest() is used to display a 5 character node by default (as
  opposed to static 12 characters)

I chose to implement the "bookmarks" view first because it is simple
and shouldn't invite too much bikeshedding that detracts from the
evaluation of `hg display` itself. But there is an important point
to consider: we now have 2 ways to show a list of bookmarks. I'm not
a fan of introducing multiple ways to do very similar things. So it
might be worth discussing how we wish to tackle this issue for
bookmarks, tags, branches, MQ series, etc.

I also made the choice of explicitly declaring the default display
template not part of the standard BC guarantees. History has shown
that we make mistakes and poor choices with output formatting but
can't fix these mistakes later because random tools are parsing
output and we don't want to break these tools. Optimizing for human
consumption is one of my goals for `hg display`. So, by not covering
the formatting as part of BC, the barrier to future change is much
lower and humans benefit.

At the aforementioned Sprint, we discussed and discarded various
alternatives to `hg display`.

We considered making `hg log ` perform this behavior. The main
reason we can't do this is because a positional argument to `hg log`
can be a file path and if there is a conflict between a path name and
a view name, behavior is ambiguous. We could have introduced
`hg log --view` or similar, but we felt that required too much typing
(we don't want to require a command flag to show a view) and wasn't
very discoverable. Furthermore, `hg log` is optimized for showing
changelog data and there are things that `hg display` could display
that aren't changelog centric.

For the command name, we would have preferred `hg show` because it is
shorter and not ambigious with any other core command. However, a
number of people have created `hg show` as effectively an alias to
`hg export`. And, some were concerned that Git users used to `git show`
being equivalent to `hg export` would be confused by a `hg show` doing
something different.

We also considered `hg view`, but that is already used by the "hgk"
extension.

"display" is an accurate description of what the command does. The
biggest concern with