summaryrefslogtreecommitdiff
path: root/builtin-blame.c
AgeCommit message (Collapse)AuthorFilesLines
2007-02-27convert object type handling from a string to a numberLibravatar Nicolas Pitre1-10/+8
We currently have two parallel notation for dealing with object types in the code: a string and a numerical value. One of them is obviously redundent, and the most used one requires more stack space and a bunch of strcmp() all over the place. This is an initial step for the removal of the version using a char array found in object reading code paths. The patch is unfortunately large but there is no sane way to split it in smaller parts without breaking the system. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20prefixcmp(): fix-up mechanical conversion.Libravatar Junio C Hamano1-3/+3
Previous step converted use of strncmp() with literal string mechanically even when the result is only used as a boolean: if (!strncmp("foo", arg, 3)) ==> if (!(-prefixcmp(arg, "foo"))) This step manually cleans them up to read: if (!prefixcmp(arg, "foo")) Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20Mechanical conversion to use prefixcmp()Libravatar Junio C Hamano1-3/+3
This mechanically converts strncmp() to use prefixcmp(), but only when the parameters match specific patterns, so that they can be verified easily. Leftover from this will be fixed in a separate step, including idiotic conversions like if (!strncmp("foo", arg, 3)) => if (!(-prefixcmp(arg, "foo"))) This was done by using this script in px.perl #!/usr/bin/perl -i.bak -p if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) { s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|; } if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) { s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|; } and running: $ git grep -l strncmp -- '*.c' | xargs perl px.perl Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17Merge branch 'maint'Libravatar Junio C Hamano1-0/+3
* maint: Update draft release notes for 1.5.0.1 Convert update-index references in docs to add. Attempt to improve git-rebase lead-in description. Do not take mode bits from index after type change. git-blame: prevent argument parsing segfault Make gitk save and restore window pane position on Linux and Cygwin. Make gitk save and restore the user set window position. [PATCH] gitk: Use show-ref instead of ls-remote [PATCH] Make gitk work reasonably well on Cygwin. [PATCH] gitk - remove trailing whitespace from a few lines. Change git repo-config to git config
2007-02-16git-blame: prevent argument parsing segfaultLibravatar Tommi Kyntola1-0/+3
The 3rd branch in builtin-blame.c should also check for lacking arguments. Running that in top dir does not trigger the problem because the 'prefix' is NULL. Signed-off-by: Tommi Kyntola <tommi.kyntola@ray.fi> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13blame: --show-stats for easier optimization work.Libravatar Junio C Hamano1-1/+4
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-06annotate: fix for cvsserver.Libravatar Junio C Hamano1-3/+6
git-cvsserver does not want the boundary commits shown any differently. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05blame: document --contents optionLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Use pretend_sha1_file() in git-blame and git-merge-recursive.Libravatar Junio C Hamano1-1/+1
git-merge-recursive wants an null tree as the fake merge base while producing the merge result tree. The null tree does not have to be written out in the object store as it won't be part of the result, and it is a prime example for using the new pretend_sha1_file() function. git-blame needs to register an arbitrary data to in-core index while annotating a working tree file (or standard input), but git-blame is a read-only application and the user of it could even lack the privilege to write into the object store; it is another good example for pretend_sha1_file(). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05git-blame: no rev means start from the working tree file.Libravatar Junio C Hamano1-25/+184
Warning: this changes the semantics. This makes "git blame" without any positive rev to start digging from the working tree copy, which is made into a fake commit whose sole parent is the HEAD. It also adds --contents <file> option to pretend as if the working tree copy has the contents of the named file. You can use '-' to make the command read from the standard input. If you want the command to start annotating from the HEAD commit, you need to explicitly give HEAD parameter. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Assorted typo fixesLibravatar Pavel Roskin1-3/+3
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-29git-blame: somewhat better commenting.Libravatar Junio C Hamano1-38/+255
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28git-blame --incremental: don't use pagerLibravatar Ren,Ai(B Scharfe1-0/+3
Starting a pager defeats the purpose of the incremental output mode. This changes git-blame to only paginate if --incremental was not given. git -p blame --incremental still starts the pager, though. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28git-blame --porcelain: quote filename in c-style when needed.Libravatar Junio C Hamano1-5/+10
Otherwise a pathname that has funny characters such as LF would screw up the parsing programs of the output. Strictly speaking, this is not backward compatible, but the current output for pathnames that have embedded LF and such cannot be sanely parsed anyway, and pathnames that only use characters from the portable pathname character set won't be affected. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28git-blame --incrementalLibravatar Linus Torvalds1-66/+107
This adds --incremental option to help GUI porcelains to show the result from git-blame incrementally. The output gives the origin information in the same format as the porcelain format. The first line has commit object name, the line number of the first line in the group in the original file, the line number of that file in the final image, and number of lines in the group. Then subsequent lines show the metainformation for the commit when the commit is shown for the first time, except the filename information is always shown (we cannot even make it conditional to -C option as blame always follows the renaming of the file wholesale). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-20Merge branch 'jc/blame'Libravatar Junio C Hamano1-2/+31
* jc/blame: blame: -b (blame.blankboundary) and --root (blame.showroot)
2006-12-20simplify inclusion of system header files.Libravatar Junio C Hamano1-4/+0
This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-18blame: -b (blame.blankboundary) and --root (blame.showroot)Libravatar Junio C Hamano1-2/+31
When blame.blankboundary is set (or -b option is given), commit object names are blanked out in the "human readable" output format for boundary commits. When blame.showroot is not set (or --root is not given), the root commits are treated as boundary commits. The code still attributes the lines to them, but with -b their object names are not shown. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-13git-blame: show lines attributed to boundary commits differently.Libravatar Junio C Hamano1-1/+14
When blaming with revision ranges, often many lines are attributed to different commits at the boundary, but they are not interesting for the purpose of finding project history during that revision range. This outputs the lines blamed on boundary commits differently. When showing "human format" output, their SHA-1 are shown with '^' prefixed. In "porcelain format", the commit will be shown with an extra attribute line "boundary". Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-29git-blame: fix rev parameter handling.Libravatar Alex Riesen1-0/+1
We lacked "--" termination in the underlying init_revisions() call which made it impossible to specify a revision that happens to have the same name as an existing file. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-28git blame -C: fix output format tweaks when crossing file boundary.Libravatar Junio C Hamano1-5/+5
We used to get the case that more than two paths came from the same commit wrong when computing the output width and deciding to turn on --show-name option automatically. When we find that lines that came from a path that is different from what we started digging from, we should always turn --show-name on, and we should count the name length for all files involved. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-10git-annotate: fix -S on graft file with comments.Libravatar Junio C Hamano1-1/+2
The graft file can contain comment lines and read_graft_line can return NULL for such an input, which should be skipped by the reader. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-08git-pickaxe: retire pickaxeLibravatar Junio C Hamano1-0/+1889
Just make it take over blame's place. Documentation and command have all stopped mentioning "git-pickaxe". The built-in synonym is left in the command table, so you can still say "git pickaxe", but it probably is a good idea to retire it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>