goldsteinn wrote: > > I don't disagree these are all potential pitfalls (and there are certainly > > more), I just don't see how having the diff code in a separate project > > ameliorates any of them. And as stated earlier, I think it in fact > > complicates them. > > The issue of "complexity" is quite subjective, a customizable function that > returns line ranges doesn't strike me as a complex API that's likely to > break/change with the benefit of easily integrating other diffing methods. > > From a user perspective it likely just means one extra package, possibly > setting a configuration value. > > Or, to avoid this PR having to handle system & version-control spesific > details - we could consider calling `vc-diff` directly to generate the diff - > this abstracts away all the details of calling git & diff directly, > personally I would still rather keep the functionality separate - then this > can be easily integrated with `hl-diff` or other packages that already track > changed lines, removing the overhead of the current method used.
`vc-diff` AFAICT won't work because it operates on files not buffer contents. It would be a nice simplifcation, although doesn't really change the fact we depend on `vc`. All things considered, I think requiring `vc` is a lot less intrusive than essentially our own `vc` wrapper.... https://github.com/llvm/llvm-project/pull/112792 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
