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

Reply via email to