On Thu, Jul 4, 2024 at 10:08 PM Elijah Newren <newren@xxxxxxxxx> wrote: > > On Wed, Jul 3, 2024 at 8:25 AM Emanuel Czirai > <correabuscar+gitML@xxxxxxxxx> 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. Thank you very much, I really appreciate knowing this very interesting info! Cheers! This also tells me that I shouldn't expect a solution for `git diff`/`git apply` any time soon, else it would've been done at that time, I suppose. It's all good, I'll find some kind of workaround for my use case. (probably something based on `diffy` as it's simpler for me to grasp than the C code) Thanks everyone. All the best!
