Repository navigation
Conversation
28746ba to
f576357
Compare
ad07059 to
e376c48
Compare
|
Pinging @gpshead as the author of #4 and @markshannon as the author of #19 since I imagine you may both have some interest in this feature due to its practicality over specifying those options through CLI flags. If you have anything to share on the solution shown here (as described in the PR description - the code is mostly inconsequential and is not covered by tests anyway) then I'd very much appreciate it to know, if this is the right direction for it. When I originally made this (it's been 3 years ago apparently, time flies 😄), I delayed completing the PR with test coverage and such since I had absolutely no clue if this would be accepted but I'd been reminded last week that it still exists so trying to move this forward. |
|
Looks like there's no interest for this, sorry. |
Description
Fixes #37
Draft because this still needs tests, testing, and documentation (documentation probably won't be added here until this solution is accepted).
The proposed solution for storing user preferences was not approved by anyone either so that might still change too if the maintainers don't agree with my proposal.
How does this work?
Now onto how this is supposed to work... User can add a configuration file at
~/.config/cherry_picker/preferences.tomlwhich looks like this:Preferences override themselves in this order (the last on the list has the highest priority):
--continue--continue// It might perhaps make more sense to swap 2 with 3 but this order was just how I ended up implementing it so I'm just leaving it as is until I get feedback on this :)
Other notes
In issue #37, I said:
But I figured that making a TOML file is actually easier to implement and maybe faster? Using
git configwould require either using a lot of subprocess calls to get all the configuration or parsing the output ofgit config --local --list, and its nesting support is limited to 3 levels, i.e.:which might be fine but is definitely limiting.