Re: `git diff`/`git apply` can generate/apply ambiguous hunks (ie. in the wrong place) (just like gnu diff/patch)

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> Yes, this is already known.  In fact, it was one of the big reasons we
> changed the default backend in rebase from apply to merge.  From the
> git-rebase manpage:

Not exactly on topic of the discussion, but I see a few things
problematic in this part, and as I already invested some time
reading it, I'd leave #leftoverbits comment here.

> ```
>    Context
>        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

`am` should be some marked-up to stand out.  It would be even better
to spell it out as `git am`.

>        with line numbers, a context region, and the actual changes. The line
>        numbers have to be taken with some fuzz, since the other side will

    "fuzz" -> "offset"

In the context of discussing patch application, `fuzz` is a term of
art.  It is the number of context lines you (the patch applicator)
allow the machinery to allow to be different between the patch and
the preimage.  Git allows *absolutely* no fuzz and there is not even
an option to loosen this (this is philosophical design decision
originating back in Linus's days).

This part is talking about something different.  `offset` is another
term of art and refers to the difference between the beginning line
number recorded in the hunk header, and the actual line in the preimage
the patch applies to.  Unless you are applying to the same preimage
as where the patch was taken from, `offset` being non-zero is
perfectly normal, but Git (and other patch applicators) try to
minimize the offset.