VC top of the tree diff and log

[Juri Linkov]

>   > vc-git.el was changed to support short logs, and vc-cvs.el to ignore the
>   > extra option (all vc backends need a similar change)
>   >
>   > WDYT?
>
> Ping.
>
> Any reason not to install this?

There is a problem in your patch.  Its "--graph" option fails in
git version 1.5.

--
Juri Linkov
http://www.jurta.org/emacs/

[Dan Nicolaescu]

Juri Linkov <juri@...> writes:

  > > After using the current solution for a bit, I've grown to like it.
  > > But that does not mean that it can't be changed...
  > > Once the backend support for generating short/long logs is in, we can
  > > decide what is the best UI for it.
  > > So I'll check in the change as it is now when I get a chance.
  >
  > Have you tried to run `vc-print-root-log' on the Emacs repository?
  > I waited for several minutes and eventually abandoned the attempt.

No, I only have the CVS one handy.
But I've tried it on other things that have lots of lines, and yes it's
slow.  See the "slow output" bugs/threads, they have been partially
motivated by this.

  > We could provide a numeric prefix argument for vc print logs
  > to limit the number of commits to show.  I mean translating it
  > to the git command like "git-log -2".

Yes, I have considered limiting the size of the log output, it needs to
apply not only to the root log, but also to C-x v l.   But I
don't know what the best thing to do here... :-(

[Juri Linkov]

>>> C-x v L l - long logs
>>> C-x v L s - short logs
>>> C-x v L r - root logs
>>> C-x v L R l - long root logs
>>> C-x v L R s - short root logs
>>
>> Ugh... that looks way too baroque.  I don't want to have to make
>> multiple decisions and follow deep branching menu structures for such a
>> common operation.  Morever, combining shifted and unshifted keys in a
>> binding _really_ slow down invocation (and raise the error rate).
>
> These commands are not too frequently used, so the speed of their
> invocation is not important.  OTOH, I see no other way to extend
> log commands to control more options like "git-log --stat",
> graph/no graph, and other pretty format options.

Strike that, I now have a better idea.

`C-u C-x v l' could ask for more additional command line arguments like
"--stat", "--graph", "--pretty", "--since", "--author", "--no-merges",
most useful of which could be added to the default value list of the
minibuffer.  This would allow the user to build complex queries.

--
Juri Linkov
http://www.jurta.org/emacs/

[Dan Nicolaescu]

Juri Linkov <juri@...> writes:

  > >   > vc-git.el was changed to support short logs, and vc-cvs.el to ignore the
  > >   > extra option (all vc backends need a similar change)
  > >   >
  > >   > WDYT?
  > >
  > > Ping.
  > >
  > > Any reason not to install this?
  >
  > There is a problem in your patch.  Its "--graph" option fails in
  > git version 1.5.

Sorry, --graph was not supposed to be enabled by default at this point.
It won't be when I actually manage to install the patch.

[Miles Bader-2]

Dan Nicolaescu <dann@...> writes:

>   > Have you tried to run `vc-print-root-log' on the Emacs repository?
>   > I waited for several minutes and eventually abandoned the attempt.
>
> No, I only have the CVS one handy.
> But I've tried it on other things that have lots of lines, and yes it's
> slow.  See the "slow output" bugs/threads, they have been partially
> motivated by this.
>
>   > We could provide a numeric prefix argument for vc print logs
>   > to limit the number of commits to show.  I mean translating it
>   > to the git command like "git-log -2".
>
> Yes, I have considered limiting the size of the log output, it needs to
> apply not only to the root log, but also to C-x v l.   But I
> don't know what the best thing to do here... :-(

What's the slowdown anyway?  The underlying git command, invoked via
`shell-command' (with output inserted into an emacs buffer) is almost
instantaneous.

Is it because it's trying to fontify and add text-props or overlays to
the entire buffer?

If that's the problem, it would obviously be _much_ more efficient to
use jit-lock or whatever, since people typically only look at like the
first 1% of such log output (if that!)...

-Miles

--
Suburbia: where they tear out the trees and then name streets after them.

[Dan Nicolaescu]

Miles Bader <miles@...> writes:

  > Dan Nicolaescu <dann@...> writes:
  > >   > Have you tried to run `vc-print-root-log' on the Emacs repository?
  > >   > I waited for several minutes and eventually abandoned the attempt.
  > >
  > > No, I only have the CVS one handy.
  > > But I've tried it on other things that have lots of lines, and yes it's
  > > slow.  See the "slow output" bugs/threads, they have been partially
  > > motivated by this.
  > >
  > >   > We could provide a numeric prefix argument for vc print logs
  > >   > to limit the number of commits to show.  I mean translating it
  > >   > to the git command like "git-log -2".
  > >
  > > Yes, I have considered limiting the size of the log output, it needs to
  > > apply not only to the root log, but also to C-x v l.   But I
  > > don't know what the best thing to do here... :-(
  >
  > What's the slowdown anyway?  The underlying git command, invoked via
  > `shell-command' (with output inserted into an emacs buffer) is almost
  > instantaneous.
  >
  > Is it because it's trying to fontify and add text-props or overlays to
  > the entire buffer?

Don't know for sure, but from what I remember last time I looked at this
the problem was not the fontification.

[Juri Linkov]

> `C-u C-x v l' could ask for more additional command line arguments like
> "--stat", "--graph", "--pretty", "--since", "--author", "--no-merges",
> most useful of which could be added to the default value list of the
> minibuffer.  This would allow the user to build complex queries.

Actually such UI already exists in PCL-CVS where a prefix argument
prompts for cvs flags.  This is very convenient.

--
Juri Linkov
http://www.jurta.org/emacs/

[Juri Linkov]

>   > >   > Have you tried to run `vc-print-root-log' on the Emacs repository?
>   > >   > I waited for several minutes and eventually abandoned the attempt.
>   > >
>   > > No, I only have the CVS one handy.
>   > > But I've tried it on other things that have lots of lines, and yes it's
>   > > slow.  See the "slow output" bugs/threads, they have been partially
>   > > motivated by this.
>   > >
>   > >   > We could provide a numeric prefix argument for vc print logs
>   > >   > to limit the number of commits to show.  I mean translating it
>   > >   > to the git command like "git-log -2".
>   > >
>   > > Yes, I have considered limiting the size of the log output, it needs to
>   > > apply not only to the root log, but also to C-x v l.   But I
>   > > don't know what the best thing to do here... :-(
>   >
>   > What's the slowdown anyway?  The underlying git command, invoked via
>   > `shell-command' (with output inserted into an emacs buffer) is almost
>   > instantaneous.
>   >
>   > Is it because it's trying to fontify and add text-props or overlays to
>   > the entire buffer?
>
> Don't know for sure, but from what I remember last time I looked at this
> the problem was not the fontification.

Yes, the problem is not the fontification.  Fontification starts only
after the git command finishes.  It is reading 500000-line output of
the complete emacs git log that takes too much time.

--
Juri Linkov
http://www.jurta.org/emacs/

[Juri Linkov]

>   > There is a problem in your patch.  Its "--graph" option fails in
>   > git version 1.5.
>
> Sorry, --graph was not supposed to be enabled by default at this point.
> It won't be when I actually manage to install the patch.

We could probe the available git command for supported command line
arguments similarly to `grep-compute-defaults'.

--
Juri Linkov
http://www.jurta.org/emacs/

[Miles Bader-2]

Juri Linkov <juri@...> writes:
> Yes, the problem is not the fontification.  Fontification starts only
> after the git command finishes.  It is reading 500000-line output of
> the complete emacs git log that takes too much time.

But if I run the same git log command using `shell-command', inserting
into an emacs buffer, it is almost instantaneous (about 2-3 seconds,
whereas vc-log takes like 3 minutes!).

-Miles

--
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

[Juri Linkov]

>>> See what I currently have.  What do you think?
>>
>> Here's an updated version that implements both top of the tree log

I think for the top of the tree log we should support doing it from the
dired buffer of the top directory of the tree.  Currently vc refuses to
do this with the error message:

  Buffer emacs is not associated with a file

where `emacs' is the top directory of the emacs git tree.

--
Juri Linkov
http://www.jurta.org/emacs/

[Stefan Monnier]

> Strike that, I now have a better idea.

> `C-u C-x v l' could ask for more additional command line arguments like
> "--stat", "--graph", "--pretty", "--since", "--author", "--no-merges",
> most useful of which could be added to the default value list of the
> minibuffer.  This would allow the user to build complex queries.

That sounds like a good idea.


        Stefan

[Miles Bader-2]

Juri Linkov <juri@...> writes:
> I think for the top of the tree log we should support doing it from the
> dired buffer of the top directory of the tree.

I agree, that would be very useful and very natural.

I tend to have dired buffers sitting around for my project anyway -- and
usually _not_ vc-dir buffers -- and I often find myself trying to use
vc-... commands in them (which fail of course), even though I know they
won't work... :/

-Miles

--
Egotist, n. A person of low taste, more interested in himself than in me.

[Dan Nicolaescu]

Juri Linkov <juri@...> writes:

  > >   > vc-git.el was changed to support short logs, and vc-cvs.el to ignore the
  > >   > extra option (all vc backends need a similar change)
  > >   >
  > >   > WDYT?
  > >
  > > Ping.
  > >
  > > Any reason not to install this?
  >
  > There is a problem in your patch.  Its "--graph" option fails in
  > git version 1.5.

Now vc-git's short log uses --graph (and --decorate).  This is what gitk
does too and it's extremely useful.
I documented in etc/NEWS that ancient versions will not support this new feature.