Open ObserverOfTime opened 4 weeks ago
Combining automatically generated code with manual tweaks sounds like it could be a problem if something goes wrong and we need to bisect/recreate. Could we separate the automatic and manual changes with different commits/PRs perhaps?
Oh, and if possible, think we could use the latest tree-sitter commit (since it shows the exact tree-sitter SHA that was used to generate)? It could become relevant to know the exact TS version if things go wrong.
Can I just specify what was manually changed instead?
That would be a good starting point. I will separate those changes into a separate commit if you can't.
If Justin won't, I will require separate atomic commits. These sort of "update repo" PRs are simply unacceptable (even though -- most of -- the changes are welcome).
Oh, and if possible, think we could use the latest tree-sitter commit (since it shows the exact tree-sitter SHA that was used to generate)
I would prefer to stick to releases for generating files; 0.25 will be a breaking change (new ABI version), and I'd like to separate that step for later (even though we'd have to wait a bit for the parser annotation).
I would prefer to stick to releases for generating files
Same, but I'm pretty sure this was not generated from a stable version but from a random commit (no idea which one). I figured if we were going with a non-release commit then at least we could pick the one the let us know which one.
Same, but I'm pretty sure this was not generated from a stable version but from a random commit (no idea which one)
Then this is another reason to ask for a change. These files should be generated with 0.24.3 (or 0.24.4 if that is imminent, in which case we should park this).
Might as well park it till 0.25 then.
tree-sitter.json
config filetree-sitter init
to create them anewCargo.lock
in versioning instructions