diff options
Diffstat (limited to 'docs/diff-internals.md')
| -rw-r--r-- | docs/diff-internals.md | 66 |
1 files changed, 35 insertions, 31 deletions
diff --git a/docs/diff-internals.md b/docs/diff-internals.md index 53e71f5b5..cf8ad5383 100644 --- a/docs/diff-internals.md +++ b/docs/diff-internals.md @@ -45,44 +45,48 @@ Internal Objects * `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. -** it is created from a repository plus a) a git_diff_file, b) a git_blob, + + * it is created from a repository plus a) a git_diff_file, b) a git_blob, or c) raw data and size -** there are three main operations on git_diff_file_content: -*** _initialization_ sets up the data structure and does what it can up to, - but not including loading and looking at the actual data -*** _loading_ loads the data, preprocesses it (i.e. applies filters) and - potentially analyzes it (to decide if binary) -*** _free_ releases loaded data and frees any allocated memory + * there are three main operations on git_diff_file_content: + + * _initialization_ sets up the data structure and does what it can up to, + but not including loading and looking at the actual data + * _loading_ loads the data, preprocesses it (i.e. applies filters) and + potentially analyzes it (to decide if binary) + * _free_ releases loaded data and frees any allocated memory * The internal structure of a `git_diff_patch` stores the actual diff between a pair of `git_diff_file_content` items -** it may be "unset" if the items are not diffable -** "empty" if the items are the same -** otherwise it will consist of a set of hunks each of which covers some - number of lines of context, additions and deletions -** a patch is created from two git_diff_file_content items -** a patch is fully instantiated in three phases: -*** initial creation and initialization -*** loading of data and preliminary data examination -*** diffing of data and optional storage of diffs -** (TBD) if a patch is asked to store the diffs and the size of the diff - is significantly smaller than the raw data of the two sides, then the - patch may be flattened using a pool of string data + + * it may be "unset" if the items are not diffable + * "empty" if the items are the same + * otherwise it will consist of a set of hunks each of which covers some + number of lines of context, additions and deletions + * a patch is created from two git_diff_file_content items + * a patch is fully instantiated in three phases: + + * initial creation and initialization + * loading of data and preliminary data examination + * diffing of data and optional storage of diffs + * (TBD) if a patch is asked to store the diffs and the size of the diff + is significantly smaller than the raw data of the two sides, then the + patch may be flattened using a pool of string data * `git_diff_output` is an internal structure that represents an output target for a `git_diff_patch` -** It consists of file, hunk, and line callbacks, plus a payload -** There is a standard flattened output that can be used for plain text output -** Typically we use a `git_xdiff_output` which drives the callbacks via the - xdiff code taken from core Git. + * It consists of file, hunk, and line callbacks, plus a payload + * There is a standard flattened output that can be used for plain text output + * Typically we use a `git_xdiff_output` which 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 -** a driver is looked up based on the name and mode of a file. -** the driver can then be used to: -*** determine if a file is binary (by attributes, by git_diff_options - settings, or by examining the content) -*** give you a function pointer that is used to evaluate function context - for hunk headers -** At some point, the logic for getting a filtered version of file content - or calculating the OID of a file may be moved into the driver. + * a driver is looked up based on the name and mode of a file. + * the driver can then be used to: + * determine if a file is binary (by attributes, by git_diff_options + settings, or by examining the content) + * give you a function pointer that is used to evaluate function context + for hunk headers + * At some point, the logic for getting a filtered version of file content + or calculating the OID of a file may be moved into the driver. |