From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: larsi@gnus.org, stephen.berman@gmx.net, 38044@debbugs.gnu.org,
juri@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 [thread overview]
Message-ID: <215302ff-8252-1f6c-5f60-aaba01cd615f@yandex.ru> (raw)
In-Reply-To: <83a78pxenu.fsf@gnu.org>
On 21.11.2019 20:33, Eli Zaretskii wrote:
>> 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".
"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.
next prev parent reply other threads:[~2019-11-21 19:08 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-03 15:17 bug#38044: 27.0.50; There should be an easier way to look at a specific vc commit Lars Ingebrigtsen
2019-11-03 15:43 ` Stephen Berman
2019-11-03 20:16 ` Juri Linkov
2019-11-13 21:03 ` Juri Linkov
2019-11-16 20:31 ` Juri Linkov
2019-11-17 11:53 ` Dmitry Gutov
2019-11-17 21:20 ` Juri Linkov
2019-11-17 21:58 ` Dmitry Gutov
2019-11-17 22:36 ` Juri Linkov
2019-11-17 23:19 ` Dmitry Gutov
2019-11-18 21:31 ` Juri Linkov
2019-11-19 3:34 ` Eli Zaretskii
2019-11-19 11:12 ` Dmitry Gutov
2019-11-19 16:12 ` Eli Zaretskii
2019-11-19 16:59 ` Dmitry Gutov
2019-11-19 17:43 ` Eli Zaretskii
2019-11-19 23:17 ` Dmitry Gutov
2019-11-20 3:43 ` Eli Zaretskii
2019-11-20 12:19 ` Dmitry Gutov
2019-11-20 16:34 ` Eli Zaretskii
2019-11-20 19:40 ` Dmitry Gutov
2019-11-20 19:57 ` Dmitry Gutov
2019-11-20 20:12 ` Eli Zaretskii
2019-11-20 20:07 ` Eli Zaretskii
2019-11-20 11:04 ` Lars Ingebrigtsen
2019-11-21 15:00 ` Eli Zaretskii
2019-11-19 22:20 ` Juri Linkov
2019-11-20 3:44 ` Eli Zaretskii
2019-11-20 21:50 ` Juri Linkov
2019-11-20 23:37 ` Dmitry Gutov
2019-11-21 23:08 ` Juri Linkov
2019-11-22 18:51 ` Dmitry Gutov
2019-11-21 14:59 ` Eli Zaretskii
2019-11-21 15:34 ` Dmitry Gutov
2019-11-21 15:50 ` Dmitry Gutov
2019-11-21 18:33 ` Eli Zaretskii
2019-11-21 19:08 ` Dmitry Gutov [this message]
2019-11-21 20:19 ` Eli Zaretskii
2019-11-21 21:05 ` Dmitry Gutov
2019-11-22 7:20 ` Eli Zaretskii
2019-11-22 19:59 ` Dmitry Gutov
2019-11-22 21:03 ` Eli Zaretskii
2019-11-22 21:43 ` Dmitry Gutov
2019-11-22 21:51 ` Eli Zaretskii
2019-11-23 13:59 ` Eli Zaretskii
2019-11-23 18:52 ` Dmitry Gutov
2019-11-21 21:15 ` Stephen Berman
2019-11-22 7:24 ` Eli Zaretskii
2019-11-22 9:25 ` Stephen Berman
2019-11-23 12:13 ` Eli Zaretskii
2019-11-23 13:16 ` Stephen Berman
2019-11-22 11:19 ` Dmitry Gutov
2019-11-22 12:12 ` Lars Ingebrigtsen
2019-11-22 13:04 ` Eli Zaretskii
2019-11-22 16:27 ` Dmitry Gutov
2019-12-01 13:13 ` Stephen Berman
2019-12-01 17:53 ` Eli Zaretskii
2019-12-01 20:43 ` Stephen Berman
2019-12-01 21:29 ` Dmitry Gutov
2019-12-01 21:39 ` Stephen Berman
2019-12-01 22:30 ` Dmitry Gutov
2019-12-02 3:34 ` Eli Zaretskii
2019-12-02 10:39 ` Dmitry Gutov
2019-12-02 11:07 ` Andreas Schwab
2019-12-02 15:58 ` Eli Zaretskii
2019-12-02 16:05 ` Dmitry Gutov
2019-11-23 18:50 ` Juri Linkov
2019-11-23 19:11 ` Dmitry Gutov
2019-11-23 22:43 ` Juri Linkov
2019-11-24 16:05 ` Eli Zaretskii
2019-11-26 23:01 ` Juri Linkov
2019-11-27 5:39 ` Eli Zaretskii
2019-11-27 22:15 ` Juri Linkov
2019-11-25 0:12 ` Dmitry Gutov
2019-11-26 23:06 ` Juri Linkov
2019-11-27 0:09 ` Dmitry Gutov
2019-11-27 5:40 ` Eli Zaretskii
2019-11-27 21:32 ` Juri Linkov
2019-11-28 3:34 ` Eli Zaretskii
2019-11-21 23:13 ` Juri Linkov
2019-11-22 8:03 ` Eli Zaretskii
2019-11-22 11:20 ` Dmitry Gutov
2019-11-22 13:06 ` Eli Zaretskii
2019-11-22 16:26 ` Dmitry Gutov
2019-11-22 16:38 ` Eli Zaretskii
2019-11-21 22:36 ` Andrii Kolomoiets
2019-11-22 7:40 ` Eli Zaretskii
2020-07-19 15:31 ` Lars Ingebrigtsen
2020-07-19 17:14 ` Dmitry Gutov
2020-07-19 17:16 ` Lars Ingebrigtsen
2020-07-19 19:43 ` Dmitry Gutov
2020-07-19 19:51 ` Lars Ingebrigtsen
2020-07-20 20:56 ` Dmitry Gutov
2020-07-21 21:44 ` Lars Ingebrigtsen
2020-07-22 15:36 ` Dmitry Gutov
2020-07-22 16:14 ` Dmitry Gutov
2020-07-22 16:25 ` Eli Zaretskii
2020-07-22 16:38 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=215302ff-8252-1f6c-5f60-aaba01cd615f@yandex.ru \
--to=dgutov@yandex.ru \
--cc=38044@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=juri@linkov.net \
--cc=larsi@gnus.org \
--cc=stephen.berman@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).