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

[Dmitry Gutov <dgutov@yandex.ru>]

On 20.11.2019 5:43, Eli Zaretskii wrote:

>>> That's true, but I'd hesitate to introduce a new class of "show"
>>> commands just because Git has it.  I see no problem showing the
>>> meta-data with diffs (when Git is the back-end), perhaps with an
>>> option to disable that.
>>
>> These two sentences seem to contradict each other. To do the latter, we
>> need to "introduce a new class of show commands". Because vc-git-diff
>> won't print any metadata.
> 
> I was talking about the VC level, not the vc-git level.  vc-git could
> have a show command, but the user of VC would still invoke a variant
> of vc-diff.

How would that even work? vc-diff will always delegate to vc-git-diff.

>>> My rationale is that other VCSes have a diff
>>> command that shows only the diffs, and that command is used "to show"
>>> a revision with those VCSes.
>>
>> IMO the log message is more important because it describes and justifies
>> what happened. Showing the diff is good as well.
> 
> That's not relevant to the issue at hand.  Like it or not, VCSes other
> than Git describe a revision by the diffs alone.

It's 100% relevant, and the fact that certain older VCSes can't do this 
should have no bearing on whether we implement a satisfactory UI in VC 
or not. That's the whole purpose of VC: make interacting with different 
VS systems easier.

>> Maybe the other VCSes don't have a simple command to do the same, but
>> they can either be called twice, or use special formatting. For
>> instance, Hg can use this command:
>>
>> hg log -r <REV> -p
> 
> IMO, this is over-engineering.  If the VCS developers don't see the
> need to have a commands which shows meta-data together with the diffs,
> we should not force that on that VCS.

They added the '-p' flag. So apparently they did see the need.

And this kind of invocation is certainly in demand (I found it in 
"answers" on StackOverflow).

> The VC level should be clean and uniform.  Any VCS-specific mindset
> should not enter it too far, or else VC will not do its job of
> insulating the user from the VCS differences well.

There's nothing VCS-specific in what I'm proposing. Any of them should 
be able to do that (though some will only manage it in two invocations).

In any case, the solution you're suggesting is trivial to implement 
indeed, but that's not what I would expect from the feature, nor, 
apparently, what Lars wanted either.