Howard Spindel <how...@sci1.com> writes: > I've just installed release 0.48 on a Windoze machine. It seems to work fine. > > However, I get a warning everytime it runs: date format '%x %X' cannot > be used for commit
Specifically, from 'mtn status'. Does this happen for other commands (it shouldn't)? > Is this something I can ignore or are commits now broken on my machine > (haven't tried one yet)? You can ignore it, but we should fix it in the point release (there will be a 0.48.1 to fix another problem). The problem is that Win32 does not have a date parsing function similar to strptime. That is used to parse dates that are formatted in a user-specified way. However, use of user-specified formatted dates is entirely optional. The reason 'status' complains is that the new commit comment editing process puts a formatted date in the commit log, so the user can change it if necessary. Then that date needs to be parsed. This is the only place in mtn that user-specified dates are parsed (there are other places where they are output). However, if the user specifies a date format that is not parseable, the commit comment editing process uses the standard date formatting (that includes all formats on Win32). So there's no reason for 'status' to complain. > If it is something I can ignore from now, it would be nice if there > were a way to get it to stop warning me. You can tell monotone to ignore it by running "mtn --no-format-dates status". You should specify the same option for commit, to avoid a similar warning. You can specify --no-format-dates as the default for status and commit in ~/.monotonerc: function get_default_command_options(command) local default_args = {} if (command[1] == "status") then table.insert(default_opts, "--no-format-dates") end if (command[1] == "commit") then table.insert(default_opts, "--no-format-dates") end return default_args end mtn developers: A partial real fix is delete the check in 'status', since the commit process can cope with unparseable user-specified date formats, whether on Win32 or Unix. However, that leaves the check in commit, which is still appropriate, for the case where the user specifies a date format that is not parseable; it partly explains why they don't see their chosen format in the commit comment they are editing. But the warning message could be clearer about that. A better real fix is to not enable user-specified dates by default; users that want them can enable them, and specify the date format they want at the same time, and worry about whether it can be parsed. I also thought we replaced %x %X by something else; why is it showing up here? -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel