user/sven/git.git/xdiff-interface.c, branch v1.5.4.4

Re(-re)*fix trim_common_tail()

2007-12-21T04:54:23Z

The tar-ball and the git archive itself is fine, but yes, the diff from 2.6.23 to 2.6.24-rc6 is bad. It's the "trim_common_tail()" optimization that has caused way too much pain. Very interesting breakage. The patch was actually "correct" in a (rather limited) technical sense, but the context at the end was missing because while the trim_common_tail() code made sure to keep enough common context to allow a valid diff to be generated, the diff machinery itself could decide that it could generate the diff differently than the "obvious" solution. Thee sad fact is that the git optimization (which is very important for "git blame", which needs no context), is only really valid for that one case where we really don't need any context. [jc: since this is shared with "git diff -U0" codepath, context recovery to the end of line needs to be done even for zero context case.] Signed-off-by: Junio C Hamano

Re-re-re-fix common tail optimization

2007-12-16T22:00:30Z

We need to be extra careful recovering the removed common section, so that we do not break context nor the changed incomplete line (i.e. the last line that does not end with LF). Signed-off-by: Junio C Hamano

trim_common_tail: brown paper bag fix.

2007-12-16T19:53:03Z

The recovered context lines were not LF terminated due to off-by-one error, which also caused the outer loop to count the number of recovered lines to terminate after running only once. Signed-off-by: Junio C Hamano

xdiff tail trimming: use correct type.

2007-12-14T20:00:42Z

Inside xdiff library, the number of context lines is represented in long, not int. Noticed by Peter Baumann. Signed-off-by: Junio C Hamano

xdi_diff: trim common trailing lines

2007-12-14T07:04:26Z

This implements earlier Linus's optimization to trim common lines at the end before passing them down to low level xdiff interface for all of our xdiff users. We could later enhance this to also trim common leading lines, but that would need tweaking the output function to add the number of lines trimmed at the beginning to line numbers that appear in the hunk headers. Signed-off-by: Junio C Hamano

xdl_diff: identify call sites.

2007-12-14T07:04:26Z

This inserts a new function xdi_diff() that currently does not do anything other than calling the underlying xdl_diff() to the callchain of current callers of xdl_diff() function. Signed-off-by: Junio C Hamano

Per-path attribute based hunk header selection.

2007-07-06T08:20:47Z

This makes"diff -p" hunk headers customizable via gitattributes mechanism. It is based on Johannes's earlier patch that allowed to define a single regexp to be used for everything. The mechanism to arrive at the regexp that is used to define hunk header is the same as other use of gitattributes. You assign an attribute, funcname (because "diff -p" typically uses the name of the function the patch is about as the hunk header), a simple string value. This can be one of the names of built-in pattern (currently, "java" is defined) or a custom pattern name, to be looked up from the configuration file. (in .gitattributes) *.java funcname=java *.perl funcname=perl (in .git/config) [funcname] java = ... # ugly and complicated regexp to override the built-in one. perl = ... # another ugly and complicated regexp to define a new one. Signed-off-by: Junio C Hamano

War on whitespace

2007-06-07T07:04:01Z

This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano

Move buffer_is_binary() to xdiff-interface.h

2007-06-05T06:07:00Z

We already have two instances where we want to determine if a buffer contains binary data as opposed to text. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Cast 64 bit off_t to 32 bit size_t

2007-03-07T19:15:26Z

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 Signed-off-by: Junio C Hamano