Follow-up Comment #1, bug #29576 (project monotone):
I understand where you're heading - but the problem is the underlying
"architecture" of this feature. _MTN/options is supposed to save options which
the user entered on command line to avoid that he has to enter them again -
while it makes no difference for it whether or not the triggered command has a
readonly-style or even needs the listed options in _MTN/options or whether the
usage of an option would even be considered harmful (f.e. mtn status -d
path/to/other.db ends up rewriting _MTN/options even if the other db does not
(!) contain the base revision of the workspace).
So if anybody wants to pick that up, we should discuss how we improve the
situation here. I'd propose two changes:
1) Save any given options back to _MTN/options at the very end of the
execution (f.e. in monotone.cc) _after_ it has been clear that no exception
occurred - so we don't remember possibly harmful settings.
2) Only save those options back to _MTN/options which have actually been
given by the user on the command line - this would probably need a little
fiddling with the <someopt>_given flag we set even for options from
_MTN/options (or we leave that alone and find another way to determine which
options have been given by the user and which not). Note that there is also a
hook which returns default command options for a command.
Alternatively we could always save back the options to _MTN/options unless
another global command line option is given, f.e. --skip-options-saving or
something similar.
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?29576>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
