bug#38044: 27.0.50; There should be an easier way to look at a specific vc commit

[Eli Zaretskii <eliz@gnu.org>]

> Cc: larsi@gnus.org, stephen.berman@gmx.net, 38044@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 21 Nov 2019 17:50:10 +0200
> 
> Okay, I see what you mean now: you're basically suggesting to tackle the 
> new behavior (the one everybody wants apparently) on top the 'diff' 
> backend action. Which can kind of work, but I don't see why we would 
> make that choice.

I think it's the logical place for such a command, because, as I said
before, in many VCSes a description of a revision _is_ the diffs of
that revision against its parent.  That is how we always presented a
revision before Git.  And "git show" also presents diffs, it just
prepends some meta-data to it.  So it's actually a minor variation of
"diff".

> Adding a new backend command is relatively cheap, and we won't force the 
> backend implementation to try to reconcile incompatible arguments (e.g. 
> REV1 that is not a parent of REV2 and SHOW-METADATA=t).

I agree that adding a command is cheap.  But it makes the system more
complex and harder to remember and make sense of.  So IMO we should
only add a new class of commands if the command is radically different
from others.

> I also think the current patch proposed by Juri is cleaner than the one 
> that is required to implement your idea.

I think the difference is very small, because the function Juri wrote
can simply be called from vc-diff given a special value of prefix arg.

> Finally, "C-u C-u C-x v =" doesn't look semantic enough for me (revision 
> != diff in my mind, at least not entirely). I think it would be nicer to 
> have a new command, but opinions welcome on this.

I think that's because you keep the command issued by the backend in
mind all the time, and that command is not "diff" for Git and
Mercurial.  But the output is almost exactly that of "diff", so IMO
the mental model is simple and easy to remember.