C-x v g going further back in time?

C-x v g going further back in time?

[Benjamin Rutt]

I love C-x v g in a file managed by CVS, I can see exactly which user
finalized which line of the file, and on which date.  This is
invaluable for answering the question of who to ask about different
lines of code.  However, sometimes that's not enough to find out who
put that line of code there originally, as sometimes people make
whitespace changes, yet C-x v g only shows the last committer of a
line so sometimes the "whitespace changer" is not the "true author" of
that line.  Is there any way to go back in time to see who committed a
given line earlier in time?
-- 
Benjamin

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

[Andrew Taylor]

Benjamin Rutt wrote:

> Is there any way to go back in time to see who committed a
> given line earlier in time?

Yes: just use C-u C-x v g and it will prompt you for a version.

-- 
Andrew

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

[Benjamin Rutt]

Benjamin Rutt <brutt+news@bloomington.in.us> writes:

> I love C-x v g in a file managed by CVS, I can see exactly which user
> finalized which line of the file, and on which date.  This is
> invaluable for answering the question of who to ask about different
> lines of code.  However, sometimes that's not enough to find out who
> put that line of code there originally, as sometimes people make
> whitespace changes, yet C-x v g only shows the last committer of a
> line so sometimes the "whitespace changer" is not the "true author" of
> that line.  Is there any way to go back in time to see who committed a
> given line earlier in time?

Since I wrote this, I see C-x v g takes a prefix argument which can
give the revision number.  But I think it's useful also to be able to
go incrementally backwards and forwards revisions, interactively, from
within the *Annotate* buffer.  I'll look at modifying vc*.el to
support this idea.
-- 
Benjamin

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

[Stefan Monnier]

> Since I wrote this, I see C-x v g takes a prefix argument which can
> give the revision number.  But I think it's useful also to be able to
> go incrementally backwards and forwards revisions, interactively, from
> within the *Annotate* buffer.  I'll look at modifying vc*.el to
> support this idea.

What I keep wanting is:
- in *vc-annotate*, clicking on the left hand side on a rev-number jumps
  to the corresponding log text in *vc* and/or show the diff in *vc-diff*.
- from the log in *vc* do C-x v g to get the *vc-annotate* of the
  rev-under-point.


-- Stefan

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

[Benjamin Rutt]

Benjamin Rutt <brutt+news@bloomington.in.us> writes:

> Since I wrote this, I see C-x v g takes a prefix argument which can
> give the revision number.  But I think it's useful also to be able to
> go incrementally backwards and forwards revisions, interactively, from
> within the *Annotate* buffer.  I'll look at modifying vc*.el to
> support this idea.

I just submitted a patch achieving this to the emacs-devel mailing
list, in case anyone is interested.
-- 
Benjamin

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

[Benjamin Rutt]

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

> What I keep wanting is:
> - in *vc-annotate*, clicking on the left hand side on a rev-number jumps
>   to the corresponding log text in *vc* and/or show the diff in *vc-diff*.
> - from the log in *vc* do C-x v g to get the *vc-annotate* of the
>   rev-under-point.

In case you didn't notice it on the emacs-devel mailing list,
something similar to the first of your two wishes has now been
implemented in CVS emacs, using the 'L' and 'D' keys for log and diff,
respectively.
-- 
Benjamin

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

[Stefan Monnier]

> In case you didn't notice it on the emacs-devel mailing list,
> something similar to the first of your two wishes has now been
> implemented in CVS emacs, using the 'L' and 'D' keys for log and diff,
> respectively.

Yes, this is becoming really neat.  And since this is like a magic lantern,
I'll just make another wish: that the new `L' key only calls `cvs log' if
the *vc* buffer doesn't already contain the proper log info: this way you
can repeatedly do `L' without each time having to wait the minute-or-so it
takes to get the complete log info.


        Stefan

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

[Benjamin Rutt]

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

>> In case you didn't notice it on the emacs-devel mailing list,
>> something similar to the first of your two wishes has now been
>> implemented in CVS emacs, using the 'L' and 'D' keys for log and diff,
>> respectively.
>
> Yes, this is becoming really neat.  And since this is like a magic lantern,
> I'll just make another wish: that the new `L' key only calls `cvs log' if
> the *vc* buffer doesn't already contain the proper log info: this way you
> can repeatedly do `L' without each time having to wait the minute-or-so it
> takes to get the complete log info.

My first cut at your feature request didn't go so well; it's tough for
two reasons:

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
   your commit was successful, or the actual log info...would it be OK
   to change 'C-x v l' to write to something other than the *vc*
   buffer, say the *vc-commit-history* buffer?

2) cache coherency problem.  What if the log info is updated b/c of
   new commits?  Do you always want the outdated log info?

Any comments on these issues?  Thanks,
-- 
Benjamin

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

[Stefan Monnier]

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

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


        Stefan

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

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

[Stefan Monnier]

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

How 'bout splitting "the cache logic" into "setting up the cache info"
(done in vc-print-log) and checking the cache (done in `L' only if you
don't want it to happen in `C-x v g') ?

The caching should not depend on the buffer's name.  Making it possible to
display logs in a different buffer would probably be good, but it should be
a completely independent decision.


        Stefan

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

[Stefan Monnier]

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

I'm not convinced it's very important.  So if it turns out to be a problem,
it might be OK to skip this part of the requirement.


        Stefan