summaryrefslogtreecommitdiff
path: root/line-range.c
AgeCommit message (Collapse)AuthorFilesLines
2018-06-15blame: prevent error if range ends past end of fileLibravatar Isabella Stephens1-1/+1
If the -L option is used to specify a line range in git blame, and the end of the range is past the end of the file, git will fail with a fatal error. This commit prevents such behavior - instead we display the blame for existing lines within the specified range. Tests are amended accordingly. This commit also fixes two corner cases. Blaming -L n,-(n+1) now blames the first n lines of a file rather than from n to the end of the file. Blaming -L ,-n will be treated as -L 1,-n and blame the first line of the file, rather than blaming the whole file. Signed-off-by: Isabella Stephens <istephens@atlassian.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-30use SWAP macroLibravatar René Scharfe1-2/+1
Apply the semantic patch swap.cocci to convert hand-rolled swaps to use the macro SWAP. The resulting code is shorter and easier to read, the object code is effectively unchanged. The patch for object.c had to be hand-edited in order to preserve the comment before the change; Coccinelle tried to eat it for some reason. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06line-range: reject -L line numbers less than 1Libravatar Eric Sunshine1-1/+4
Since inception, git-blame -L has been documented as accepting 1-based line numbers. When handed a line number less than 1, -L's behavior is undocumented and undefined; it's also nonsensical and should be diagnosed as an error. Do so. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06line-range: teach -L^:RE to search from start of fileLibravatar Eric Sunshine1-2/+7
The -L:RE option of blame/log searches from the end of the previous -L range, if any. Add new notation -L^:RE to override this behavior and search from start of file. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06line-range: teach -L:RE to search from end of previous -L rangeLibravatar Eric Sunshine1-5/+7
For consistency with -L/RE/, teach -L:RE to search relative to the end of the previous -L range, if any. The new behavior invalidates one test in t4211 which assumes that -L:RE begins searching at start of file. This test will be resurrected in a follow-up patch which teaches -L:RE how to override the default relative search behavior. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06line-range: teach -L^/RE/ to search from start of fileLibravatar Eric Sunshine1-2/+8
The -L/RE/ option of blame/log searches from the end of the previous -L range, if any. Add new notation -L^/RE/ to override this behavior and search from start of file. The new ^/RE/ syntax is valid only as the <start> argument of -L<start>,<end>. The <end> argument, as usual, is relative to <start>. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06line-range: teach -L/RE/ to search relative to anchor pointLibravatar Eric Sunshine1-4/+26
Range specification -L/RE/ for blame/log unconditionally begins searching at line one. Mailing list discussion [1] suggests that, in the presence of multiple -L options, -L/RE/ should search relative to the endpoint of the previous -L range, if any. Teach the parsing machinery underlying blame's and log's -L options to accept a start point for -L/RE/ searches. Follow-up patches will upgrade blame and log to take advantage of this ability. [1]: http://thread.gmane.org/gmane.comp.version-control.git/229755/focus=229966 Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05blame: reject empty ranges -L,+0 and -L,-0Libravatar Eric Sunshine1-1/+1
Empty ranges -L,+0 and -L,-0 are nonsensical in the context of blame yet they are accepted (in fact, both are interpreted as -L1,Y where Y is end-of-file). Report them as invalid. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05blame: reject empty ranges -LX,+0 and -LX,-0Libravatar Eric Sunshine1-0/+2
Empty ranges -LX,+0 and -LX,-0 are nonsensical in the context of blame yet they are accepted (in fact, both are interpreted as -LX,+2). Report them as invalid. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-17line-range: fix "blame -L X,-N" regressionLibravatar Eric Sunshine1-0/+7
"blame -L X,-N" is documented as blaming "N lines ending at X". In practice, the behavior is achieved by swapping the two range endpoints if the second is less than the first. 25ed3412 (Refactor parse_loc; 2013-03-28) broke this interpretation by removing the swapping code from blame.c and failing to add it to line-range.c along with other code relocated from blame.c. Thus, such a range is effectively treated as empty. Fix this regression. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-28log -L: :pattern:file syntax to find by funcnameLibravatar Thomas Rast1-1/+135
This new syntax finds a funcname matching /pattern/, and then takes from there up to (but not including) the next funcname. So you can say git log -L:main:main.c and it will dig up the main() function and show its line-log, provided there are no other funcnames matching 'main'. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-28Implement line-history search (git log -L)Libravatar Thomas Rast1-1/+18
This is a rewrite of much of Bo's work, mainly in an effort to split it into smaller, easier to understand routines. The algorithm is built around the struct range_set, which encodes a series of line ranges as intervals [a,b). This is used in two contexts: * A set of lines we are tracking (which will change as we dig through history). * To encode diffs, as pairs of ranges. The main routine is range_set_map_across_diff(). It processes the diff between a commit C and some parent P. It determines which diff hunks are relevant to the ranges tracked in C, and computes the new ranges for P. The algorithm is then simply to process history in topological order from newest to oldest, computing ranges and (partial) diffs. At branch points, we need to merge the ranges we are watching. We will find that many commits do not affect the chosen ranges, and mark them TREESAME (in addition to those already filtered by pathspec limiting). Another pass of history simplification then gets rid of such commits. This is wired as an extra filtering pass in the log machinery. This currently only reduces code duplication, but should allow for other simplifications and options to be used. Finally, we hook a diff printer into the output chain. Ideally we would wire directly into the diff logic, to optionally use features like word diff. However, that will require some major reworking of the diff chain, so we completely replace the output with our own diff for now. As this was a GSoC project, and has quite some history by now, many people have helped. In no particular order, thanks go to Jakub Narebski <jnareb@gmail.com> Jens Lehmann <Jens.Lehmann@web.de> Jonathan Nieder <jrnieder@gmail.com> Junio C Hamano <gitster@pobox.com> Ramsay Jones <ramsay@ramsay1.demon.co.uk> Will Palmer <wmpalmer@gmail.com> Apologies to everyone I forgot. Signed-off-by: Bo Yang <struggleyb.nku@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-28Refactor parse_locLibravatar Bo Yang1-0/+92
We want to use the same style of -L n,m argument for 'git log -L' as for git-blame. Refactor the argument parsing of the range arguments from builtin/blame.c to the (new) file that will hold the 'git log -L' logic. To accommodate different data structures in blame and log -L, the file contents are abstracted away; parse_range_arg takes a callback that it uses to get the contents of a line of the (notional) file. The new test is for a case that made me pause during debugging: the 'blame -L with invalid end' test was the only one that noticed an outright failure to parse the end *at all*. So make a more explicit test for that. Signed-off-by: Bo Yang <struggleyb.nku@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>