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: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
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: Fri, 22 Nov 2019 09:20:02 +0200

> Cc: larsi <at> gnus.org, stephen.berman <at> gmx.net, 38044 <at> debbugs.gnu.org,
>  juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 21 Nov 2019 23:05:07 +0200
> 
> On 21.11.2019 22:19, Eli Zaretskii wrote:
> 
> > Here's an alternative proposal.  It seems like almost all VCS backends
> > we support provide a variant of a "log" command that shows the diffs
> > together with the usual meta-data shown by "log".  Only RCS and CVS
> > don't have such an option of "log", all the rest do (most of them via
> > "log -p").
> 
> Somewhat better, but all backends would have to be updated anyway, for 
> this to work.

It's new functionality, so that goes without saying.  Or did you mean
something specific when you said "updated"?

> So the change in VC backend API is comparable to adding a new
> action.

We don't necessarily need a change in the API: vc-print-log-internal
has enough arguments to pass this new meaning to it and to the
backends.  But even if there's a change in the API, it isn't a
catastrophe from my POV.

> I don't mind this too much (asking vc-git-print-log to include the diffs 
> makes sense, at least), but doing it this way loses out on the 
> opportunity to support all backends in one fell swoop.

I don't understand why would we lose that opportunity.  We will have
to write new code for each backend in any alternative, and the code to
add is really quite simple, so I'm probably missing something here,
but what?

> I hardly see myself ever choosing 'C-u C-u C-x v L' instead of 'M-x 
> vc-print-revision'. Simply because I'll never remember the former.

That's fine.

> Are you really that against a new command?

Yes, more or less.  IMO, we already have too many of them.  VC used to
be simple and elegant, and this proliferation of too many high-level
commands makes it more and more complex, and inevitably causes us
tweak the user level and UI to this or that particular VCS, which is
wrong in the long run.

Previous Next

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