mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-06 01:03:02 +01:00
Code Activity
git/Documentation/line-range-format.txt

30 lines
941 B
Text
Raw Normal View History

line-range-format.txt: clarify -L:regex usage form blame/log documentation describes -L option as: -L<start>,<end> -L:<regex> <start> and <end> can take one of these forms: * number * /regex/ * +offset or -offset * :regex which is incorrect and confusing since :regex is not one of the valid forms of <start> or <end>; in fact, it must be -L's lone argument. Clarify by discussing :<regex> at the same indentation level as "<start> and <end>...": -L<start>,<end> -L:<regex> <start> and <end> can take one of these forms: * number * /regex/ * +offset or -offset If :<regex> is given in place of <start> and <end> ... Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06 15:59:35 +02:00
<start> and <end> can take one of these forms:
Refactor parse_loc 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>
2013-03-28 17:47:30 +01:00
- number
+
If <start> or <end> is a number, it specifies an
absolute line number (lines count from 1).
+
- /regex/
+
This form will use the first line matching the given
line-range-format.txt: document -L/RE/ relative search Option -L/RE/ of blame/log now searches relative to the previous -L range, if any. Document this. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06 15:59:44 +02:00
POSIX regex. If <start> is a regex, it will search from the end of
the previous `-L` range, if any, otherwise from the start of file.
line-range: teach -L^/RE/ to search from start of file 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-06 15:59:45 +02:00
If <start> is ``^/regex/'', it will search from the start of file.
line-range-format.txt: document -L/RE/ relative search Option -L/RE/ of blame/log now searches relative to the previous -L range, if any. Document this. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06 15:59:44 +02:00
If <end> is a regex, it will search
Refactor parse_loc 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>
2013-03-28 17:47:30 +01:00
starting at the line given by <start>.
+
- +offset or -offset
+
This is only valid for <end> and will specify a number
of lines before or after the line given by <start>.
log -L: :pattern:file syntax to find by funcname 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-28 17:47:33 +01:00
+
line-range-format.txt: clarify -L:regex usage form blame/log documentation describes -L option as: -L<start>,<end> -L:<regex> <start> and <end> can take one of these forms: * number * /regex/ * +offset or -offset * :regex which is incorrect and confusing since :regex is not one of the valid forms of <start> or <end>; in fact, it must be -L's lone argument. Clarify by discussing :<regex> at the same indentation level as "<start> and <end>...": -L<start>,<end> -L:<regex> <start> and <end> can take one of these forms: * number * /regex/ * +offset or -offset If :<regex> is given in place of <start> and <end> ... Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06 15:59:35 +02:00
If ``:<regex>'' is given in place of <start> and <end>, it denotes the range
log -L: :pattern:file syntax to find by funcname 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-28 17:47:33 +01:00
from the first funcname line that matches <regex>, up to the next
line-range: teach -L:RE to search from end of previous -L range 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-06 15:59:46 +02:00
funcname line. ``:<regex>'' searches from the end of the previous `-L` range,
if any, otherwise from the start of file.
line-range: teach -L^:RE to search from start of file 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-06 15:59:47 +02:00
``^:<regex>'' searches from the start of file.
Copy permalink