It would be great if the context, changed with task context <> would be written to a differnet file and not the main rc file. I think that some users like myself, are using version control to maintain their taskrc file and changing the context all the time marks the file as changed in this directory. A configuration value like contextfile would be great.
BTW I tried using an include statement to workaround this but what currently task does is just putting context=<> in the end of ~/.taskrc which ovverides what is written in the included configuration file.
I'm using the stable 2.5.1 version right now and I tried 2.6.0 as well and it acts the same.
As a workaround, maybe you could try doing the opposite ? have a separate versioned.taskrc that's saved by your system, and source it from the .taskrc that task uses to store the context ?
Yea I guess that should work.
Since I've already opened a discussion about the context setting, I was thinking a little bit further about it and I was wondering, perhaps it could be even better to have an environmental variable for the context instead of / in addition to the ~/.taskrc setting?
This is planned for a future release. State information will be written to something like ~/.task/staterc, which includes context, and some new information.
Sounds wonderful :smiley:, can't wait to see the next release!
I'd like to second this.
My situation is roughly the same: Taskwarrior deployed by a config management system (ansible).
I saw ~/.taskrc as a config file. When changing the context withint taskwarrior I was suprised as well to see that file changing. I'd argue that the configuration file is not the place to store an application status.
Most helpful comment
Sounds wonderful :smiley:, can't wait to see the next release!