feat(Git): support reading language from git attributes #565

Though I wonder whether this information should even go into .gitattributes specifically? It's not really VCS-specific, and isn't going to be used by Git. I mean I guess so, since Mergiraf is "just" a merge driver, so a sub-tool of Git. But maybe this could be the start of the mergiraf.toml configuration file 👀

Thanks a lot for this initiative! I can relate to the need.
Before diving too deep in the specifics of the implementation, I think it's worth gathering consensus on whether the overall approach is the one we want to go for. This is useful to avoid wasting work on the fine details of this PR if we end up choosing another solution.

At the moment, one way to achieve this is to register a separate merge driver, which contains the appropriate --language option in the CLI invocation. For instance, in .gitconfig:

[merge "mergiraf"]
    name = mergiraf
    driver = mergiraf merge --git %O %A %B -s %S -x %X -y %Y -p %P -l %L
    
[merge "mergiraf-myjs"]
    name = mergiraf
    driver = mergiraf merge --git  --language javascript %O %A %B -s %S -x %X -y %Y -p %P -l %L

and then in .gittatributes

*.py merge=mergiraf
*.java merge=mergiraf
*.myjs merge=mergiraf-myjs

Obviously, it's not super convenient, but it's already one way to do it. So, one approach to addressing the need could consist in just documenting this approach (not saying it's necessarily the best one).

If we are not satisfied with this UX, then it's worth thinking about all the sorts of things we want to let users configure. Association of filenames to languages is one thing, but there could be many others:

• tweaking the language profile, for instance as suggested in #249 by enabling specific commutative parents
• setting a specific timeout value for some file types, or other types of configuration (--fast, --compact…)

I think there is value in keeping configuration contained in not too many different places (for usability but also to avoid having to read many files at runtime), so I don't know if it's worth starting reading .gitattributes ourselves. It might not prove very convenient to extend later on. And as @ada4a mentioned, it might tie mergiraf to git a bit more, making it harder to use it with other VCS (which I think is a worthy goal to keep in mind).

@ada4a wrote in #565 (comment):

Though I wonder whether this information should even go into .gitattributes specifically? It's not really VCS-specific, and isn't going to be used by Git. I mean I guess so, since Mergiraf is "just" a merge driver, so a sub-tool of Git. But maybe this could be the start of the mergiraf.toml configuration file 👀

git already supports things like:

• specifying globs
• unsetting it for exceptions

While it is not VCS-specific, other VCS tools don't have attributes like this though. jj has a feature request issue to implement it; hg doesn't AFAICS either.

I've found attributes a good place to store these kinds of details about files (even if Git itself doesn't care). For example, in our projects, we use it to indicate which files should be formatted. So we have format.clang-format=16 means "format this file using clang-format version 16. For vendored third party projects, we can the unset this (e.g., if we set that for "all *.cxx files" so that we are not reformatting vendored code).

Not necessarily disagreeing with you @mathstuf, but globbing at least we could implement thanks to glob

reading .gitattributes ourselves

somewhat of a tangent: one could argue that a merge driver should be able to ask Git to pass to it attribute values for the to-be-merged file during invocation -- that kind of already happens with %L, with which a merge driver can get the value of the conflict-marker-size attribute

Obviously, it's not super convenient, but it's already one way to do it. So, one approach to addressing the need could consist in just documenting this approach (not saying it's necessarily the best one).

I think it is a solution, yes. However, with a single merge=mergiraf, I can rely on a global "I know about a mergiraf merge driver. With custom drivers like this, I am "required" to have in-repo instructions for each special override. Global settings may conflict with other settings.

I do doubt it to really be an issue in practice, but Prolog and Perl do both share the .pl extension and if both get support, I think something like this would be very useful for whichever loses the default extension/language link (likely Prolog…but it is probably far easier to have support here for Prolog given the relative syntactic complexity of the two).

somewhat of a tangent: one could argue that a merge driver should be able to ask Git to pass to it attribute values for the to-be-merged file during invocation -- that kind of already happens with %L, with which a merge driver can get the value of the conflict-marker-size attribute

That does seem useful. However, that would require some kind of markup to suppress the --language flag if it is unset or unspecified.

I think an unset value would be plain wrong, because I'm pretty sure that that does mean false, so a bool, whereas we require a string. So we could emit a warning in that case.

But otherwise we could handle the two cases the same – I'm pretty sure the language field is already an Option, and so we can set it to None on both unset and unspecified

Thanks both for your points! I've thought about it more and .gitattributes does seem like a good fit. I like @ada4a's idea of introducing a dedicated configuration file for the tool, as it would give us a lot of control over its structure, having it accommodate a lot more configuration settings, but I also see advantages to using gitattributes:

• as @mathstuf wrote, git's existing cascading logic to look up attributes (be they checked into git or not, repository-specific or global) is quite helpful
• I can imagine it being useful to rely on other attributes. For instance the linguist ones, which seem to be a sort of standard by now. We could access all those attributes at no further cost, with the existing invocation of git check-attr.

If we want to introduce a mergiraf.toml config file, it should still be possible to do that later… I guess we'll have to keep the git check-attr call for backwards compatibility but it doesn't feel like an outrageously costly thing to do.

So I'm happy to go ahead with this approach :)

Right, about the linguist attributes -- it seems that they're indeed a bit of a standard, so maybe we should just use them instead of mergiraf.language? Though we should check whether they call their languages the same way we do

Circling back to this: I think it would be worth addressing the points @ada4a raised and after that it seems to me that it would be good to merge.

I'm traveling and won't be able to make a release before end of next week (since it still relies on a cross-compilation set up that I only have on another machine - I know… I have it as a goal to migrate that to the CI instead). So I would aim to make the release then, so perhaps it could be nice to merge this PR before that? I'm happy to help incorporate @ada4a's points if needed.

I'm not allowed to edit this PR so I'm proposing to continue it in #599.