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: Fri, 22 Nov 2019 21:59:14 +0200

[Message part 1 (text/plain, inline)]

On 22.11.2019 9:20, Eli Zaretskii wrote:

>> 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"?

Not every new functionality needs explicit support from backends.

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

The backend API. It also has certain backward compatibility expectations.

Anyway, I'm saying the change you are proposing is roughly the same 
magnitude in complexity as adding a new backend action.

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

Not necessarily. See the attached patch (it's a modification of Juri's).

Since we don't have a way to combine async process invocation, there is 
some complexity there with accept-process-output. But from what I see, 
the diff operation is considerably more resource-intensive, at least for 
big Hg repos.

There is a catch, however: it requires an implementation of 
region-history-mode. But, as you remarked, it can be extracted to be 
more backend-independent.

Consequently, for now this "default" implementation only adds 
print-revision support to Hg.

> VC used to
> be simple and elegant, and this proliferation of too many high-level
> commands makes it more and more complex,

I hardly see any complexity in the presence of a command. There's more 
more of it in tiny details of implementation of the main ones.

> and inevitably causes us
> tweak the user level and UI to this or that particular VCS, which is
> wrong in the long run.

When was the last time we did that? And how adding a new command would 
cause it in this case?

[vc-print-revision-with-default.diff (text/x-patch, attachment)]

Previous Next

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