aboutsummaryrefslogtreecommitdiff
path: root/builtin-blame.c
Commit message (Collapse)AuthorAge
* Merge branch 'maint'Junio C Hamano2007-05-06
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: Small correction in reading of commit headers Documentation: fix typo in git-remote.txt Add test for blame corner cases. blame: -C -C -C blame: Notice a wholesale incorporation of an existing file. Fix --boundary output diff format documentation: describe raw combined diff format Mention version 1.5.1 in tutorial and user-manual Add --no-rebase option to git-svn dcommit Fix markup in git-svn man page
| * blame: -C -C -CJunio C Hamano2007-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you do this, existing "blame -C -C" would not find that the latter half of the file2 came from the existing file1: ... both file1 and file2 are tracked ... $ cat file1 >>file2 $ git add file1 file2 $ git commit This is because we avoid the expensive find-copies-harder code that makes unchanged file (in this case, file1) as a candidate for copy & paste source when annotating an existing file (file2). The third -C now allows it. However, this obviously makes the process very expensive. We've actually seen this patch before, but I dismissed it because it covers such a narrow (and arguably stupid) corner case. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * blame: Notice a wholesale incorporation of an existing file.Junio C Hamano2007-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | The -C option to blame tries to find a section of a preimage file by running diff against the lines whose origin is still unknown, and excluding the different parts. The code however did not cover the case where the tail part of the section matched, which we handle for the normal non-move/copy codepath. This breakage was most visible when preimage file matches in its entirety and failed to pass blame in such a case. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | blame: use .mailmap unconditionallyJunio C Hamano2007-05-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There really isn't any point in turning off .mailmap. The number of mailmap lookups are bounded by number of lines in the target file, and the real blame processing is much more expensive. If it turns out to be too costly, we should optimize the mailmap lookup itself, instead of avoiding the call. If the author information of commits of the project are relatively clean, .mailmap would have only small number of entries, and the overhead of looking it up will not be high. On the other hand, if the author information is really screwed up that a good .mailmap needs to be maintained to run shortlog, giving uncleaned names in blame output is not helpful at all either. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Remove pointless calls to access(2) when checking for .mailmapAlex Riesen2007-04-30
| | | | | | | | | | | | | | | | | | | | read_mailmap already returns not 0 in case of error, and nothing seem to be interested in it. It also is silent about the fact (read_mailmap being to chatty would justify the call to access, but there is no point for it to be and it isn't). Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Apply mailmap in git-blame output.Junio C Hamano2007-04-29
| | | | | | | | | | | | | | This makes git-blame to use the same mailmap used by git-shortlog. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | blame -s: suppress author name and time.Junio C Hamano2007-04-29
|/ | | | | | | With this "git blame -b -s HEAD~n..HEAD" becomes a nicer way to review the result of recent changes in context. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Update git-annotate/git-blame documentationAndrew Ruder2007-04-16
| | | | | | | | | | | | | | | | | | | | | | | Moved options that pertained to both git-blame and git-annotate to a common file blame-options.txt. builtin-blame.c: Removed --compatibility, --long, --time from the short usage as they are not handled in the code. Documentation/git-blame.txt: Removed common options to git-annotate. Added documentation for --score-debug. Removed --compatibility. Adjusted usage at top to not wrap on 80 columns. Documentation/git-annotate.txt: Using common options blame-options.txt. Documentation/blame-options.txt: Added -b note about associated config option, added --root note about associated config option, added documentation for --show-stats. Removed --long, --time, --rev-file as those options do not really exist. Added documentation for -M/-C taking an optional score argument for detection of moved lines. Signed-off-by: Andrew Ruder <andy@aeruder.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-blame: Fix overrun in fake_working_tree_commit()Michael Spang2007-04-14
| | | | | | | git-blame would overflow commit->buffer when annotating files with long paths. Signed-off-by: Michael Spang <mspang@uwaterloo.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
* blame: cmp_suspect is not "cmp" anymore.Junio C Hamano2007-03-20
| | | | | | | | | The earlier round makes the function return "is it different" and it does not return a value suitable for sorting anymore. Reverse the logic to return "are they the same suspect" instead, and rename it to "same_suspect()". Signed-off-by: Junio C Hamano <junkio@cox.net>
* blame: micro-optimize cmp_suspect()Junio C Hamano2007-03-19
| | | | | | | | The commit structures are guaranteed their uniqueness by the object layer, so we can check their address and see if they are the same without going down to the object sha1 level. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Cast 64 bit off_t to 32 bit size_tShawn O. Pearce2007-03-07
| | | | | | | | | | | | | | | | | | Some systems have sizeof(off_t) == 8 while sizeof(size_t) == 4. This implies that we are able to access and work on files whose maximum length is around 2^63-1 bytes, but we can only malloc or mmap somewhat less than 2^32-1 bytes of memory. On such a system an implicit conversion of off_t to size_t can cause the size_t to wrap, resulting in unexpected and exciting behavior. Right now we are working around all gcc warnings generated by the -Wshorten-64-to-32 option by passing the off_t through xsize_t(). In the future we should make xsize_t on such problematic platforms detect the wrapping and die if such a file is accessed. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* General const correctness fixesShawn O. Pearce2007-03-07
| | | | | | | | | | | | | | | | We shouldn't attempt to assign constant strings into char*, as the string is not writable at runtime. Likewise we should always be treating unsigned values as unsigned values, not as signed values. Most of these are very straightforward. The only exception is the (unnecessary) xstrdup/free in builtin-branch.c for the detached head case. Since this is a user-level interactive type program and that particular code path is executed no more than once, I feel that the extra xstrdup call is well worth the easy elimination of this warning. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* convert object type handling from a string to a numberNicolas Pitre2007-02-27
| | | | | | | | | | | | | | | 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>
* prefixcmp(): fix-up mechanical conversion.Junio C Hamano2007-02-20
| | | | | | | | | | | | | 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>
* Mechanical conversion to use prefixcmp()Junio C Hamano2007-02-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'maint'Junio C Hamano2007-02-17
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * git-blame: prevent argument parsing segfaultTommi Kyntola2007-02-16
| | | | | | | | | | | | | | | | | | 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>
* | blame: --show-stats for easier optimization work.Junio C Hamano2007-02-13
|/ | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* annotate: fix for cvsserver.Junio C Hamano2007-02-06
| | | | | | git-cvsserver does not want the boundary commits shown any differently. Signed-off-by: Junio C Hamano <junkio@cox.net>
* blame: document --contents optionJunio C Hamano2007-02-05
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Use pretend_sha1_file() in git-blame and git-merge-recursive.Junio C Hamano2007-02-05
| | | | | | | | | | | | | | | | 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>
* git-blame: no rev means start from the working tree file.Junio C Hamano2007-02-05
| | | | | | | | | | | | | | | | | 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>
* Assorted typo fixesPavel Roskin2007-02-03
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-blame: somewhat better commenting.Junio C Hamano2007-01-29
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-blame --incremental: don't use pagerRen,Ai(B Scharfe2007-01-28
| | | | | | | | | | | 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>
* git-blame --porcelain: quote filename in c-style when needed.Junio C Hamano2007-01-28
| | | | | | | | | | | | | 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>
* git-blame --incrementalLinus Torvalds2007-01-28
| | | | | | | | | | | | | | | | | 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>
* Merge branch 'jc/blame'Junio C Hamano2006-12-20
|\ | | | | | | | | * jc/blame: blame: -b (blame.blankboundary) and --root (blame.showroot)
| * blame: -b (blame.blankboundary) and --root (blame.showroot)Junio C Hamano2006-12-18
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | simplify inclusion of system header files.Junio C Hamano2006-12-20
|/ | | | | | | | | | | | | | | | | | | | 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>
* git-blame: show lines attributed to boundary commits differently.Junio C Hamano2006-12-13
| | | | | | | | | | | | | 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>
* git-blame: fix rev parameter handling.Alex Riesen2006-11-29
| | | | | | | | 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>
* git blame -C: fix output format tweaks when crossing file boundary.Junio C Hamano2006-11-28
| | | | | | | | | | | 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>
* git-annotate: fix -S on graft file with comments.Junio C Hamano2006-11-10
| | | | | | | | 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>
* git-pickaxe: retire pickaxeJunio C Hamano2006-11-08
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>