Re: C-x v g going further back in time?

[Benjamin Rutt]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 1) the *vc* buffer is used both for 'C-x v l' and also when you do
>>    'C-x v v' to commit a file, so it might contain either info that
>
> It can also be used for another file.  I think we just need to add
> a variable that stores the "it's a log" info, along the one that stores the
> file's name.

I guess a buffer-local variable will do in the *vc* buffer; this new
variable would have a default value of nil, and will only be set to
something meaningful when the log message history is requested.

>> 2) cache coherency problem.  What if the log info is updated b/c of
>>    new commits?  Do you always want the outdated log info?
>
> I wouldn't worry too much about it.  If the commits are done via VC,
> they'll overwrite the *vc* buffer so it's safe.  And even if it
> somehow does not happen, it's rather unlikely that the user will be
> bothered by the lack of some brand new commits: when using
> vc-annotate you're typically looking at past changes.  And you can
> always add a `revert-buffer-function' such that the user can refresh
> explicitly the log info.

I was actually thinking of putting the cache logic into
`vc-print-log', which can be invoked independently of the 'C-x v g',
'C-x o', 'L' path.  But I think if they invoke 'C-x v l' directly,
though, they should get the latest info always, otherwise they might
wonder if their recent commit actually succeeded, since the log
wouldn't show it if it was cached.  Hmm.  The logic for setting up the
"*vc*" buffer is inside `vc-print-log', so it seems wrong to put the
cache logic that refers to that buffer outside of that method.  Maybe
`vc-print-log' should take an argument that names the buffer, and has
a reasonable default of "*vc*" when called interactively?  What do you
think?
-- 
Benjamin