On Mon, Oct 30, 2023 at 9:24 AM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 2023-10-30 at 15:54:14, Taylor Blau wrote: > > On Sat, Oct 28, 2023 at 11:24:06PM -0700, Elijah Newren wrote: > > > But...wouldn't you already have the conflicts generated when doing the > > > merge and learning that it fails? Why would you need to generate them > > > again? > > > > brian would know better than I do, but I believe the reason is because > > the "attempt this merge" RPC is handled separately from the "show me the > > merge conflict(s) at xyz path". Those probably could be combined > > (obviating the need for this patch), but doing so is probably rather > > complicated. > > That's correct. They could in theory happen at different times, which > is why they're not linked. Maybe this is digging a little into "historical reasons" too much, but this still seems a little funny. If they happen at different times, you still need multiple pieces of information remembered from the merge operation in order for git-merge-file to be able to regenerate the conflict correctly in general. In particular, you need the OIDs and the filenames. Trying to regenerate a conflict without remembering those from the merge step would only work for common cases, but would be problematic in the face of either renames being involved or recursive merges or both. And if you need to remember information from the merge step, then why not remember the actual conflicts (or at least the tree OID generated by the merge operation, which has the conflicts embedded within it)? I know, I know, there's probably just historical cruft that needs cleaning up, and I don't think any of this matters to the patch at hand since it's independently useful. It just sounds like a system has been set up that has some rough edge cases caused by a poor splitting. > -- > brian m. carlson (he/him or they/them) > Toronto, Ontario, CA
