Custom merge driver or something for semver_status.md
semver_status.md gets lots of merge conflicts, which are typically textual but not semantic. It would be nice to do something better about this.
git has some machinery which might help, but we need to consider how to do this in a way that requires the least amount of configuration by each contributors. (git's custom merge machinery won't run arbitrary stuff without local config, for obviousl reasons.)
Activity
added Next Q2 Technical Debt labels
assigned to @Diziet
Another possibility is to make a separate SEMVER file for each crate directory.
edited for clarity
Edited by Nick Mathewson
Yes. Let us consider the following plan:
- Break
semvar_status.mdinto filescrates/*/semver_status.md(or whatever name you prefer) - Mark them all to be merged with the
uniondriver via.gitattributes.
The things that will go wrong if we do this are:
-
If two people try to fix the same error, or change the same line, both of their versions will end up in the result. This is fine - I presume you as release technician will have no difficulty resolving that at release time.
-
If a branch adds something, but, in between, arti is released, and all the lines are deleted, the merge will complete reinstate the old file. This will be done silently and automatically, possibly during gitlab auto-merge resulting in a broken file on
main.
I think this latter point isn't fine. Countermeasures and alternatives:
-
Spot this in the CI.
mainwould start failing its CI in this scenario. There would have to be a manual disentanglement. -
Use a different file for each release. This is going to be super annoying. In the bad scenario old files would be resurrected and the lines would have to be transferred to the new file. Nnng.
-
Use a different file for every change. What a performance.
-
Split the file but keep the default merge driver. This will avoid conflicts where one person adds an entry for crate A and another for crate B. IMO this is not the most common kind of conflict. I don't think this is worth the effort.
-
Custom merge driver using some existing program. Disadvantage: developers have to set it in their git config (this cannot be done centrally unless we want to bring back cargo-husky :-) for the very same reaosns). Also, I'm not sure that the right program exists? Something that would do "setwise" merging would probably suffice, especially if we split the files. I really think git itself should come with one of these!
-
Custom merge driver with our own program. Same disadvantage as above, but now we need everyone to install this merge utility too.
Bah.
- Break
-
Oh here's an idea:
Do the
unionthing but somehow nobble it so that it won't happen in gitlab. Eg, do theunionthing but via a local name for the existing builtin union driver, so that everyone must configure it locally. Consequences:- Expert contributors who want this must configure it locally. They will get the union behaviour and risk making bad files
- We can cause the CI to fail when the file is one made by an expert that a bad merge (empirically the resulting file has both Arti versions in it).
- Naive contributors get the existing conflict behaviour which they will know how to deal with.
- gitlab won't do this broken thing during automatic merge creation. Instead, it would ask the user to resolve conflict, resulting in one of the above scenarios.
added Doing label
removed Doing label
removed Next label
added Doing label
mentioned in merge request !545 (merged)
mentioned in commit c9552220
mentioned in merge request !571 (merged)
added Roadmap::Future label and removed Backlog label
removed Q3 label
It's been some time since the new rules on semver status. I'm not the one most impacted but I feel like things go smother now, and I don't think having some complex machinery would be very useful.
I propose for this ticket to be re-triaged and possibly closed if others share my viewpoint, or completed with what's still problematic if there are still problems.