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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 6, 2024, 05:43 UTC
Message-ID: <xmqq5xtj5b3s.fsf@gitster.g>
In-Reply-To: <CABPp-BGVdQZCr=0NzY9vpUJqaH+5yxJdpvfUqqhtWB4V=nkwDw@mail.gmail.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.

Show 5 quoted lines

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