Both 'git log' and 'git blame' support the same format
of '-L' arguments, so we refactor its description into
a new file.
And it is possible to use more than one '-L' option
for each path.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t4301-log-line-single-history.sh:
test the linear line of history.
t/t4302-log-line-merge-history.sh:
test the case that there are merges in the history.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Always print the interesting ranges even if the current
commit does not change any line of it.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makes the line level log output look good when used
with the '--graph' option.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Walking forward through history (i.e., topologically earliest
commits first), we filter the parent list of every commit as
follows. Consider a parent P:
- If P touches any of the interesting line ranges, we keep it.
- If P is a merge and it takes all the interesting line ranges
from one of its parents, P is rewritten to this parent, else
we keep P.
- Otherwise, P is rewritten to its (only) parent P^.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function rewrite_one is used to rewrite a single
parent of the current commit, and is used by rewrite_parents
to rewrite all the parents.
Decouple the dependence between them by making rewrite_one
a callback function that is passed to rewrite_parents. Then
export rewrite_parents for reuse by the line history browser.
We will use this function in line.c.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To correctly track the line ranges over several branches,
we must make sure that we have processed all children before
reaching the commit itself.
Thus we introduce a first pass in cmd_line_log that runs
prepare_revision_walk to achieve the topological ordering.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'struct line_chunk' is used to make sure each file is scanned
only once when printing the lines. We track the starting line
number and the offsets of all lines in the range in this struct.
We use two functions from diff.c to generate meta info and hunk
headers in the usual format.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When going from a commit to its parents, we map the "interesting"
range of lines according to the change made.
For non-merge commit, we just run map_range on the ranges, which
works as follows:
1. Run diffcore_std to find out the pre/postimage for each file.
2. Run xdi_diff_hunks on each interesting set of pre/postimages.
3. The map_range_cb callback is invoked for each hunk by the diff
engine, and we use it to calculate the pre-image range from the
post-image range in the function map_lines.
For merge commits, we run map_range once for every parent.
Simultaneously we use a take_range pass to eliminate all ranges
that are identical. If any ranges remain after that, then the
merge is considered non-trivial.
The algorithm that maps lines from post-image to pre-image is in
the function map_lines. Generally, we use simple line number
calculation method to do the map.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since diff_line_range can form a single list through its
'next' pointer, we provide two kind of clone.
diff_line_range_clone:
used to clone only the element node and set the
element's 'next' pointer to NULL.
diff_line_range_clone_deeply:
used to clone the whole list of ranges.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use fill_metainfo to fill the line level diff meta data,
emit_line to print out a line and quote_two to quote
paths.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the two new APIs of parse options added in the previous
commit, we parse the multiple '-L n,m <pathspec>' syntax.
Notice that users can give more than one '-L n,m' for each pathspec.
And a pathspec with all its '-L' options maps to a single
diff_line_range structure.
This has the exactly the same semantics as 'git blame -L n,m <pathspec>'
because we refactored and reused the blame code.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Both 'git blame -L' and 'git log -L' parse the same style
of line number arguments, so put the 'parse_loc' function
to line.c and export it.
The caller of parse_loc should provide a callback function
which is used to calculate the start position of the nth line.
Other parts such as regexp search, line number parsing are
abstracted and re-used.
Note that, we can use '$' to specify the last line of a file.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'struct diff_line_range' is the main data structure to keep
track of the line ranges we are currently interested in. The
user starts digging from a line range, and after examining the
diff that affects that range by a commit, we can find a new
range that corresponds to this range. So, we will associate this
new range with the commit's parent commit.
There is one 'diff_line_range' for each file, and there are
multiple 'struct line_range' in each 'diff_line_range'. In this way,
we support multiple ranges.
Within 'struct line_range', there are multiple 'struct print_range'
which represent a diff hunk.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
1. parse_options_current: get the current option/argument the API
is dealing with;
2. parse_options_next: skip the current argument, moving to the
next one. Unless 'keep' is set, discard the skipped argument
from the final argument list.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make parse_options_step() report PARSE_OPT_NON_OPTION instead
of PARSE_OPT_DONE to the caller, when it sees a non-option argument.
This will help implementing a nonstandard option syntax that
takes more than one parameters to an option, e.g.
-L n1,m1 pathspec1 -L n2,m2 pathspec2
by directly calling parse_options_step(). The parse_options() API
only calls parse_options_step() once, and its callers are not affected
by this change.
Thanks-to: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These two tests weren't about how "git reflog show <branch>" exits when
there is no reflog, but were about "checkout" and "branch" create or not
create reflog when creating a new <branch>. Update the tests to check
what we are interested in, using "git rev-parse --verify".
Also lose tests based on "test -f .git/logs/refs/heads/<branch>" from
nearby, to avoid exposing this particular implementation detail
unnecessarily.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The correct advice should have been taken from c289c31 (t/t7006: ignore
return status of shell's unset builtin, 2010-06-02). A real-life issue
we experienced was with "unset", not with "export" (exporting an
unset variable may have similar portability issues, though).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The '!()' notation is interpreted as a pattern-list on Ksh. The Ksh man
page describe it as follows:
!(pattern-list)
Matches anything except one of the given patterns.
Ksh performs a file glob using the pattern-list and then tries to execute
the first file in the list. If a space is added between the '!' and the
open parens, then Ksh will not interpret it as a pattern list, but in this
case, it is preferred to use test_must_fail, so lets do so.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These two lines use the negation '!' operator to negate the result of a
simple command. Since these commands do not contain any pipes or other
complexities, the test_must_fail function can be used and is preferred
since it will additionally detect termination due to a signal.
This was noticed because the second use of '!' does not include a space
between the '!' and the opening parens. Ksh interprets this as follows:
!(pattern-list)
Matches anything except one of the given patterns.
Ksh performs a file glob using the pattern-list and then tries to execute
the first file in the list. If a space is added between the '!' and the
open parens, then Ksh will not interpret it as a pattern list, but in this
case, it is preferred to use test_must_fail, so lets do so.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some have found the wording of the description to be somewhat ambiguous
with respect to when it is desirable to use test_must_fail instead of
"! <git-command>". Tweak the wording somewhat to hopefully clarify that
it is _because_ test_must_fail can detect segmentation fault that it is
desirable to use it instead of "! <git-command>".
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This prevents a buffer overrun that could otherwise be triggered by
creating a file called '.git' with contents
gitdir: (something really long)
Signed-off-by: Greg Brockman <gdb@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The correct responses to a D and a T line in .git/objects/info/packs
are the same, so combine their case arms. In both cases we already
‘goto’ out of the switch so while at it, remove a redundant ‘break’
to avoid yet another line of code.
Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Reviewed-by: Jonathan Nieder <jrnieder <at> gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All the git add options were listed in the synopsis until the
--ignore-missing option was added. Change that so that the git add
documentation now has the complete listing.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git submodule add no longer implicitly adds with --force. Remove
references to the old functionality in the documentation.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To make the behavior of "git submodule add" more consistent with "git add"
ignored submodule paths should not be silently added when they match an
entry in a .gitignore file. To be able to override that default behavior
in the same way as we can do that for "git add", the new option "--force"
is introduced.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git mergetool' creates '*.orig' backup files in its
default configuration. Mention this in its documentation.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apparently using the Storable module during global destruction is
unsafe - there is a bug which can cause segmentation faults:
http://rt.cpan.org/Public/Bug/Display.html?id=36087http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482355
The persistent memoization support introduced in commit 8bff7c538
relied on global destruction to write cached data, which was leading
to segfaults in some Perl configurations. Calling Memoize::unmemoize
in the END block forces the cache writeout to be performed earlier,
thus avoiding the bug.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Acked-by: Eric Wong <normalperson@yhbt.net>
The current make target 'aggregate-results' scanned all files matching
test-results/t*-*. Normally these are only the test counts (and the
exit values, which are ignored), but with --tee the suite also dumps
all output. Furthermore, with --verbose t1450 contains several lines
starting with "broken link from ..." which matches the criteria used
by aggregate-results.sh.
Rename the counts output files to *.counts, and only scan those.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The svn-fe tool takes a Subversion dump file as input and produces
a fast-import stream as output. This can be useful as a low-level
tool in building other importers, or for debugging the vcs-svn
library.
make svn-fe
make svn-fe.1
to test.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier we tried to make sure that the trees we get are what A...B
syntax produced, by checking that earlier ones are all marked
uninteresting (which has to be true as they are merge bases),
there are two remaining ones that are interesting, and they are
marked as non-symmetric-left and symmetric-left respectively.
The "the last two must be interesting" condition is however wrong when one
is an ancestor of the other between A and B (i.e. fast-forward). In such
a case, one of them is marked uninteresting.
* jn/paginate-fix:
git --paginate: paginate external commands again
git --paginate: do not commit pager choice too early
tests: local config file should be honored from subdirs of toplevel
t7006: test pager configuration for several git commands
t7006 (pager): introduce helper for parameterized tests
Conflicts:
t/t7006-pager.sh
* mg/revision-doc:
Documentation: link to gitrevisions rather than git-rev-parse
Documentation: gitrevisions
Documentation: split off rev doc into include file
