Use git to produce better merge conflicts for rewrite #939
Conversation
Previously, we were producing simple conflict markers by placing both the original and generated code into conflict markers. if git is available, pass the original and new version through git to produce a more fine grained set of conflicts. * gptel-rewrite.el (gptel--git-merge-conflicts, gptel--rewrite-merge, gptel--simple-merge-conflicts): Implement by using two new functions to handle simple and git-based merging. These functions accept the original and replacement strings as arguments.
* gptel-rewrite.el (gptel--rewrite-merge-git) (gptel--rewrite-merge-simple): Rename from `gptel--git-merge-conflicts' and `gptel--simple-merge-conflicts'. (gptel--rewrite-merge): Modify the request buffer directly instead of passing strings around. Use `call-process' instead of `shell-command-to-string', which generates a lot more garbage.
karthink
force-pushed
the
meain/git-conflicts
branch
from
23742ad to
62f644b
Compare
|
Thanks @meain. I rewrote the two functions to act on buffer regions instead of passing strings. (The previous, "functional" approach is garbage heavy.) Can you check if they still work correctly? |
Aah, that is something I had not considered.
Yup, looks good to me :D |
|
Merged, thanks for the PR @meain!
To be fair, it's not much of an issue since the text being rewritten will usually consist of a few paragraphs or functions at most, which isn't much garbage even when it's duplicated twice as a string and again across three separate buffers (as happens when using But I never touch working gptel code to improve performance -- plenty of other things to do! So I thought it might be worth getting it right the first time here. |
2 participants
Previously, we were producing simple conflict markers by just putting original and generated code into conflict markers. In this implementation, if we have git available, we pass the original and new version through git to produce a more fine grained set of conflicts.
Fixes #932