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

>
> On Wed, Jul 3, 2024 at 8:25 AM Emanuel Czirai
> <correabuscar+gitML@gmail.com> wrote:
> >
> > Subject: `git diff`/`git apply` can generate/apply ambiguous hunks (ie. in the wrong place) (just like gnu diff/patch)
>
> 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:
>
> ```
>    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
>        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
>        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 areas of the
>        code have the same surrounding lines of context, the wrong one can be
>        picked. There are real-world cases where this has caused commits to be
>        reapplied incorrectly with no conflicts reported. Setting diff.context
>        to a larger value may prevent such types of problems, but increases the
>        chance of spurious conflicts (since it will require more lines of
>        matching context to apply).
>
>        The merge backend works with a full copy of each relevant file,
>        insulating it from these types of problems.
> ```
>
> > This doesn't affect `git rebase` as it's way more robust than simply
> > extracting the commits as patches and re-applying them. (I haven't looked
> > into `git merge` though, but I doubt it's affected)
>
> This was not always true; and, in fact, rebase is actually still
> partially affected today -- if you pick the `apply` backend or pick
> arguments that imply that backend, then you can still run into this
> problem.  The merge backend (the default) is unaffected, and this
> problem was one of the big reasons for us switching to make the merge
> backend the default instead of the apply backend.
>
> git merge is unaffected.