From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:15
I know, I know, use pickaxe :-)
Any suggestions as to how to implement a not-too-slow annotate that
looks reasonable enough so as to fool real cvs clients? Let's assume
I'll have the "per-file-version numbers" to translate commit SHA1s
into cvs-ish version numbers in a magic hat, right next to the fluffy
bunnies.
Suggestions of GIT machinery that would shortcut the trip from
git-rev-list HEAD $path
to a annotate-ish output. Did I dream it or is qgit showing something
annotate-ish in its screenshots?
Note! Just told a white lie: I won't be actually using git-rev-list.
Instead, I'll have a rev list that will gloss over branched
development, picking only one "path" of the history every time
(initially using the algorithm formerly known as rand() ) , and
showing merge commits as one.
cheers,
martin
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:15
Hi,
On Fri, 16 Dec 2005, Martin Langhoff wrote:
I know, I know, use pickaxe :-)
Any suggestions as to how to implement a not-too-slow annotate that
looks reasonable enough so as to fool real cvs clients?
For starters, you could use my attempt:
http://www.gelato.unsw.edu.au/archives/git/0508/7171.html
It does not fool any CVS user, because it does not fake version numbers.
Instead, you can display SHA1s, short SHA1s, author names, or mixtures
thereof.
However, I learnt to use git-whatchanged in the meantime, and I'll
probably never go back.
Hth,
Dscho
Not bad at all! I might simplify it a bit (won't need the commitmsg
parsing), and see if how fast I can make it.
It does not fool any CVS user,
Ah, no. Those have been fooled already ;-)
However, I learnt to use git-whatchanged in the meantime, and I'll
probably never go back.
Of course. I'm trying to meet a few the expectations of popular cvs
clients (cli, TortoiseCVS, Eclipse, etc). If a workable git-annotate
falls out of this, oh well.
OTOH, yours didn't get included. Any particular reasons? (other than
stressing the point that you should use whatchanged/pickaxe?)
Also! On 12/16/05, Junio C Hamano [off-list ref] wrote:
I haven't actively done anything but one of the good things that
could happen is to split out the access routines for annotate
database qgit build when run the first time in the repository,
and make them available to other Porcelains. There is no need
to reinvent the wheel.
That would be cool! Though my particular implementation may be a tad
unconventional in its view of the "file history" as a strictly linear
thing. Normal git porcelains don't even blink when dealing with
branching/merging development histories.
cheers,
martin
Not bad at all! I might simplify it a bit (won't need the commitmsg
parsing), and see if how fast I can make it.
NOTE! You can make it a whole lot faster these days by passing the path
down to git-rev-list. But as usual, I'm perl-incompatible, so I can't help
you with that modification.
OTOH, yours didn't get included. Any particular reasons? (other than
stressing the point that you should use whatchanged/pickaxe?)
I'd love to see a git-annotate, but I want it to be efficient enough that
it's not embarrassing.
For example, "git-whatchanged" is certainly efficient enough, and you
could just parse that output (possible without using -p and comparing file
contents on your own against the current HEAD as you progress backwards)
Or, you could now use "git-rev-list <rev> <filename>", which is even more
efficient, but the downside of that is that it computes the _full_ graph
before it starts outputting the early ones.
But, for example:
[torvalds@g5 linux-history]$ time git-whatchanged drivers/char/Makefile > /dev/null
real 0m37.993s
user 0m41.912s
sys 0m0.400s
[torvalds@g5 linux-history]$ time git-rev-list HEAD drivers/char/Makefile > /dev/null
real 0m6.713s
user 0m6.656s
sys 0m0.056s
that's the old Linux history thing, with 60,000+ commit. The path-based
git-rev-list thing cuts it down to just 103 commits you need to look at
(so the annotate itself should be really fast, and the cost really is all
in that "git-rev-list" thing).
Of course, with the current kernel tree, the git-rev-list takes a lot less
time, and only results in six commits, but that's a tree that only has a
few months of history, so when looking at performance, you really should
look at some bigger tree.
NOTE! You can also decide to cut down on time by saying "annotate back
only to a specific date", ie something like
git-rev-list $(git-rev-parse --since=2.years.ago HEAD) drivers/char/Makefile
which limits the thing by filename _and_ date (a good way to handle really
really big projects) where the rev-parse might otherwise be very
expensive.
And, of course, a quality implementation will notice when a file
disappears, and use "git-diff-tree -M" on that commit to see if it was
renamed, and then continuing with the old name...
Linus
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:42:15
On Fri, 16 Dec 2005, Linus Torvalds wrote:
On Fri, 16 Dec 2005, Nicolas Pitre wrote:
quoted
On Fri, 16 Dec 2005, Linus Torvalds wrote:
quoted
But, for example:
[torvalds@g5 linux-history]$ time git-whatchanged drivers/char/Makefile > /dev/null
real 0m37.993s
user 0m41.912s
sys 0m0.400s
Hmmm... I'd like to have a system like that too, where reality is
smaller than the sum of system and user time. ;-)
It's called "smp".
Gah! Maybe I should have tried the same before posting, since I get
this on my P4 with HT:
real 0m36.930s
user 0m41.971s
sys 0m0.656s
/me hides shamefully
Nicolas