Hello,
Custom merge drivers [1] provide a convenient way to extend Git's merge
algorithms. But as far as I can tell, there is no way to access the
pathnames and revisions of the files to merge. Those would be very
useful to generate informative conflict markers, like the built-in merge
strategies do.
For instance, when merging with the ort strategy and diff3 conflict
style, I get markers such as:
<<<<<<< HEAD:main/my_file.txt
…
||||||| 194c4190b:main/my_file.txt
…
=======
…
>>>>>>> origin/branch:main/my_renamed_file.txt
Those strings at the end of conflict markers, with the revision and the
pathname, are very useful to understand which parts are coming from where.
When implementing a custom merge driver, I don't see how to access this
information to include it in the conflict markers. Custom merge drivers
are typically invoked on temporary files generated by Git with
uninformative paths, such as ".merge_file_NgiKjJ".
Therefore, my merge driver is only able to generate conflicts which look
like this:
<<<<<<< .merge_file_NgiKjJ
…
||||||| .merge_file_D1XtCW
…
=======
…
>>>>>>> .merge_file_WbmrBA
Of course, in a given rebase/merge session, the order in which the
conflicting parts will be presented will remain consistent, so I will
generally be able to remember which revision each part corresponds to,
but it's still a mental load I would ideally try to avoid. Also, if the
rename detection heuristics have false positives, then I can get merge
conflicts which come from unrelated files: in that case it is very
useful to see the pathnames, to understand this situation better.
So, I wonder: would people be open to exposing additional parameters to
merge drivers? For instance we could add parameters "%X", "%Y" "%Z" to
expose those "revision:pathname" strings for each part. (I think colons
cannot be part of revision names, so this can be parsed unambiguously by
the custom merge driver to recover the revision and pathname
independently, if needed.)
I would be happy to submit a patch for this if you think this makes
sense. If it is already possible to access this information in another
way, I would like to work on documenting that.
Best wishes,
Antonin
[1]: https://git-scm.com/docs/gitattributes#_defining_a_custom_merge_driver
