GNU bug report logs - #38044
27.0.50; There should be an easier way to look at a specific vc commit

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, stephen.berman <at> gmx.net, 38044 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#38044: 27.0.50; There should be an easier way to look at a specific vc commit
Date: Thu, 21 Nov 2019 21:08:49 +0200

On 21.11.2019 20:33, Eli Zaretskii wrote:
>> Cc: larsi <at> gnus.org, stephen.berman <at> gmx.net, 38044 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> 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".

"As I said before", when a revision is created, we fill in a number of 
different fields, most importantly, the commit message. That's in every 
VCS except some ancient ones. So to show a revision means to show all 
that stuff.

The fact that some VCS's command line doesn't provide an easy way to do 
this is incidental.

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

An awkward implementation is even harder to make sense of. And creating 
a function that does something different based on an optional argument 
is bad programming.

Anyway, we could implement this new command using *zero* new backend 
actions. Even without calling 'git show'.

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

Does this make sense for anybody else here?

For me, the diff command, even VCS diff, is about showing differences 
between file trees, or states of the file system. Not about describing 
one revision.

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

Not necessarily. And see above.

> But the output is almost exactly that of "diff", so IMO
> the mental model is simple and easy to remember.

We all have our biases. You apparently dislike Git (VCS used by most of 
everybody these days, including our users) and prefer the way command 
line interfaces looked in previous systems. That's a valid preference, 
but it's unlikely to reflect the expectations of most of our users.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.