Diff is broken into four phases:
In the source code, step 1 is implemented in
src/diff.c, step 2 in
src/diff_tform.c, step 3 in
src/diff_patch.c, and step 4 in
src/diff_print.c. Additionally, when it comes to accessing file
content, everything goes through diff drivers that are implemented in
git_diff_optionsrepresents user choices about how a diff should be performed and is passed to most diff generating functions.
git_diff_filerepresents an item on one side of a possible delta
git_diff_deltarepresents a pair of items that have changed in some way - it contains two
git_diff_fileplus a status and other stuff.
git_diff_listis a list of deltas along with information about how those particular deltas were found.
git_diff_patchrepresents the actual diff between a pair of items. In some cases, a delta may not have a corresponding patch, if the objects are binary, for example. The content of a patch will be a set of hunks and lines.
hunkis range of lines described by a
git_diff_range(i.e. "lines 10-20 in the old file became lines 12-23 in the new"). It will have a header that compactly represents that information, and it will have a number of lines of context surrounding added and deleted lines.
lineis simple a line of data along with a
git_diff_line_tvalue that tells how the data should be interpreted (e.g. context or added).
git_diff_file_content is an internal structure that represents the
data on one side of an item to be diffed; it is an augmented
git_diff_file with more flags and the actual file data.
there are three main operations on git_diff_file_content:
The internal structure of a
git_diff_patch stores the actual diff
between a pair of
a patch is fully instantiated in three phases:
git_diff_output is an internal structure that represents an output
target for a
git_xdiff_outputwhich drives the callbacks via the xdiff code taken from core Git.
git_diff_driver is an internal structure that encapsulates the logic
for a given type of file