The documentation to "git rebase" says that the line numbers (in the rebased change) may not exactly be the same as the line numbers the change gets replayed on top of the new base, but uses a wrong noun "fuzz". It should have said "offset". They are both terms of art. "fuzz" is about context lines not exactly matching. "offset" is about the difference in the location that a change was taken from the original and the change gets replayed on the target. "offset" is often inevitable and part of normal life. "fuzz" on the other hand is often a sign of trouble (and indeed "Git" refuses to apply a change with "fuzz", except there are options to be fuzzy about whitespaces). Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> --- Documentation/git-rebase.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git c/Documentation/git-rebase.txt w/Documentation/git-rebase.txt index 74df345f9e..b18cdbc023 100644 --- c/Documentation/git-rebase.txt +++ w/Documentation/git-rebase.txt @@ -737,7 +737,7 @@ The 'apply' backend works by creating a sequence of patches (by calling `format-patch` internally), and then applying the patches in sequence (calling `am` internally). Patches are composed of multiple hunks, each with line numbers, a context region, and the actual changes. The -line numbers have to be taken with some fuzz, since the other side +line numbers have to be taken with some offset, since the other side will likely have inserted or deleted lines earlier in the file. The context region is meant to help find how to adjust the line numbers in order to apply the changes to the right lines. However, if multiple
