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

31 lines
982 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
+
Documentation: change -L:<regex> to -L:<funcname> The old wording was somehow implying that <start> and <end> were not regular expressions. Also, the common case is to use a plain function name here so <funcname> makes sense (the fact that it is a regular expression is documented in line-range-format.txt). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-20 14:09:06 +02:00
If ``:<funcname>'' is given in place of <start> and <end>, it is a
regular expression that denotes the range from the first funcname line
that matches <funcname>, up to the next funcname line. ``:<funcname>''
searches from the end of the previous `-L` range, if any, otherwise
from the start of file. ``^:<funcname>'' searches from the start of
file.
Copy permalink