Solves #65 - Uses git-graph.toml to parse commits message format#71
Solves #65 - Uses git-graph.toml to parse commits message format#71KarlHeitmann wants to merge 3 commits intogit-bahn:masterfrom
Conversation
|
Another solution that will avoid modifying BTW, if you have better name for |
|
Sorry, a bit short in time at the moment. So some more patience required until I can take a deeper look... Could you please check if the |
|
Don't worry, I am not in a hurry. EDIT: Yes, I've run
|
|
I would prefer to have both settings in the same file, and to use To make things consistent, setting the format permanently should work like setting the model permanently. This would also help to avoid that users are required to edit the file, and make the example file from #70 unnecassary. Given that more settings could be permanent, maybe a different CLI syntax for permanent settings would be better. Now, it works like this: Maybe something like this would be better for permanent settings: |
Intro
This solves #65 , it is a proof of concept and I think needs some iteration. To test it, copy the sample below into the file
.git/git-graph.toml(you can put whatever you want on format="whateveryouwant" following the rules oncargo run -- --helpsection--format)Questions
Can I recycle the file that is already being used here to get the model name, and add the "format" key-value pair to get the format by config file? If we want to use the same file to store all default custom settings permanently, we need to wrap inside an
Optionthemodelandformatattributes for RepoSettings and CommitFormatToml, as you can see on the second commit. If we don't wrap these attributes inside anOption, the program will crash if the config file has onlymodel="simple", or has onlyformat="blabla"key-value pair.The rest is implementation details, should I move the new code that tries to parse the config file from
src/main.rstosrc/config.rs? Is there a better way to not have so much nested matches? Every feedback is welcome.