bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
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@gnus.org, stephen.berman@gmx.net, 38044@debbugs.gnu.org,
>  juri@linkov.net
> From: Dmitry Gutov <dgutov@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]