1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-01 06:47:52 +01:00
Commit graph

60 commits

Author SHA1 Message Date
Fredrik Kuivinen
27e7304567 blame: Rename detection (take 2)
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-10 22:22:20 -08:00
Junio C Hamano
690e307f54 blame: unbreak "diff -U 0".
The commit 604c86d15b changed the
original "diff -u0" to "diff -u -U 0" for portability.

A big mistake without proper testing.

The form "diff -u -U 0" shows the default 3-line contexts,
because -u and -U 0 contradicts with each other; "diff -U 0" (or
its longhand "diff --unified=0") is what we meant.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-06 00:32:50 -08:00
Junio C Hamano
604c86d15b blame: avoid "diff -u0".
As Linus suggests, use "diff -u -U 0" instead.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05 16:02:44 -08:00
Junio C Hamano
cfea8e077b blame and annotate: show localtime with timezone.
Earlier they showed gmtime and timezone, which was inconsistent
with the way our commits and tags are pretty-printed.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05 16:02:44 -08:00
Junio C Hamano
a0fb95e319 blame: avoid -lm by not using log().
... as suggested on the list.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05 16:02:44 -08:00
Fredrik Kuivinen
ea4c7f9bf6 git-blame: Make the output human readable
The default output mode is slightly different from git-annotate's.
However, git-annotate's output mode can be obtained by using the
'-c' flag.

Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05 14:49:58 -08:00
Junio C Hamano
9201c70742 Const tightening.
Mark Wooding noticed there was a type mismatch warning in git.c; this
patch does things slightly differently (mostly tightening const) and
was what I was holding onto, waiting for the setup-revisions change
to be merged into the master branch.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05 02:47:29 -08:00
Fredrik Kuivinen
fc675b8cd5 git-blame, take 2
Here is an updated version of git-blame. The main changes compared to
the first version are:

* Use the new revision.h interface to do the revision walking
* Do the right thing in a lot of more cases than before. In particular
  parallel development tracks are hopefully handled sanely.
* Lots of clean-up

It still won't follow file renames though.

There are still some differences in the output between git-blame and
git-annotate. For example, in 'Makefile' git-blame assigns lines
354-358 to 455a7f3275 and git-annotate
assigns the same lines to 79a9d8ea0d.

I think git-blame is correct in this case. This patterns occur in
several other places, git-annotate seems to sometimes assign lines to
merge commits when the lines actually changed in some other commit
which precedes the merge.

[jc: I have conned Ryan into doing test cases, so that it would
help development and fixes on both implementations.  Let the
battle begin! ;-) ]

Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-02 15:10:39 -08:00
Junio C Hamano
c40610422e Merge part of 'lt/rev-list' into 'fk/blame'
Now blame will depend on the new revision walker infrastructure,
we need to make it depend on earlier parts of Linus' rev-list
topic branch, hence this merge.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-02 15:10:05 -08:00
Fredrik Kuivinen
cbfb73d73f Add git-blame, a tool for assigning blame.
I have also been working on a blame program. The algorithm is pretty
much the one described by Junio in his blame.perl. My variant doesn't
handle renames, but it shouldn't be too hard to add that. The output
is minimal, just the line number followed by the commit SHA1.

An interesting observation is that the output from my git-blame and
your git-annotate doesn't match on all files in the git
repository. One example where several lines differ is read-cache.c. I
haven't investigated it further to find out which one is correct.

The code should be considered as a work in progress. It certainly has
a couple of rough edges. The output looks fairly sane on the few files
I have tested it on, but it wouldn't be too surprising if it gets some
cases wrong.

[jc: adding it to pu for wider comments. I did minimum
whitespace fixups but it still needs an indent run and
-Wdeclaration-after-statement fixups.]

Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-21 00:54:34 -08:00