On 2/16/17, Artur Shepilko <nomadb...@gmail.com> wrote: > Is this some undocumented Fossil feature which is supposed to allow > overriding of the commit timestamp?
Yes. You can change the displayed date of any check-in using a date tag. This feature is designed to fix check-ins that were made from a system with a mis-set system clock. The date tag is used to resolve "time-warps" such as https://www.sqlite.org/src/timeline?c=3f30f00a - (Please do not attempt to resolve that particular timewarp - it is one we use for testing.) The original check-in date is preserved and the new date is shown as an edit. For example in https://www.sqlite.org/src/info/e37137376a2b2306 you can see both the original check-in date and the revised check-in date set by the tag at https://www.sqlite.org/src/info/e864e83c133bfd55 > Nevertheless, in either case the date tag values are ignored in the > timeline for both commits; the original timestamp is being used. > > If date tag is indeed a way to tune the timeline, perhaps this should > be factored in both the timeline output and the selection of export > recordset. The revised date (according to the most recent and current date tag) is the date that is in the EVENT table in the MTIME field. That the EVENT.MTIME field is what drives the timeline display. And it should also be driving the git export, I suppose. The original date of the check-in is shown in the EVENT.OMTIME field > > > > On Thu, Feb 16, 2017 at 4:54 PM, Artur Shepilko <nomadb...@gmail.com> wrote: >> Indeed, in export.c the commits are lined up chronologically. >> >> There's a way to try to catch such inconsistencies by tracking when >> the "from :mark" gets freshly incremented (that is the parent has not >> been exported yet): >> src/export.c::~581 >> int next_mark = unused_mark; >> zMark = mark_name_from_rid(pid, &unused_mark); >> if ( unused_mark == next_mark+1 ){ >> /* Handle a "future" parent commit */ >> } >> printf("from %s\n", zMark); >> >> Still, this will need a restructuring of the export flow. >> This may also become a run-away problem, once we start chasing the >> parent commit-chain through potential merges etc. > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users