- 22 3月, 2006 1 次提交
-
-
由 Luck, Tony 提交于
Using "size_t" values for printf field width/precision upsets gcc, it wants to see an "int". Signed-off-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 18 3月, 2006 2 次提交
-
-
由 Fredrik Kuivinen 提交于
Before this patch git-blame <directory> gave non-sensible output. (It assigned blame to some random file in <directory>) Abort with an error message instead. Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Fredrik Kuivinen 提交于
As pointed out by Junio, it may be dangerous to cut off people's names after 15 bytes. If the name is encoded in an encoding which uses more than one byte per code point we may end up with outputting garbage. Instead of trying to do something smart, just output the entire name. We don't gain much screen space by chopping it off anyway. Furthermore, only output the file name if we actually found any renames. Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 11 3月, 2006 1 次提交
-
-
由 Fredrik Kuivinen 提交于
Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 06 3月, 2006 5 次提交
-
-
由 Junio C Hamano 提交于
The commit 604c86d1 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: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
As Linus suggests, use "diff -u -U 0" instead. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Earlier they showed gmtime and timezone, which was inconsistent with the way our commits and tags are pretty-printed. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
... as suggested on the list. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Fredrik Kuivinen 提交于
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: NFredrik Kuivinen <freku045@student.liu.se> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 05 3月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 03 3月, 2006 1 次提交
-
-
由 Fredrik Kuivinen 提交于
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 455a7f32 and git-annotate assigns the same lines to 79a9d8ea. 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: NFredrik Kuivinen <freku045@student.liu.se> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 21 2月, 2006 1 次提交
-
-
由 Fredrik Kuivinen 提交于
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: NFredrik Kuivinen <freku045@student.liu.se> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-