Looking closer at the timeline and manifests shows that the inconsistency is with https://www.sqlite.org/src/info/590d4ac1ee0db824 which lists as its parent a tag's manifest (https://www.sqlite.org/src/info/f228c7ca0682c370). Normally the link should be to tag's target object, which in this case is https://www.sqlite.org/src/info/eb7a544fe49d1626.
Now, this could be fixed with "fossil reparent" command (the manifest won't be changed): fossil reparent 590d4ac1ee0db824 eb7a544fe49d1626bacecfe53ddc03fe082e3243 This fix seems to allow the git fast-import to proceed past this ... until it finds another inconsistency, unrelated to the one above. This time it's with commit: https://www.sqlite.org/src/info/3f30f00a384d2358 Again, looking at the timeline https://www.sqlite.org/src/timeline?r=trunk&d=2010-09-28 There's a unusual timeline zig-zag on 2010-09-29, where a "future" commit (https://www.sqlite.org/src/info/655991ec8a781d67) is a parent to a "past" commit above. Apparently, there was some time skew which crept in. Same happened with the another subsequent "future" commit (https://www.sqlite.org/src/info/1ef0dc9328f47506, parent to "past" https://www.sqlite.org/src/info/f34dc54d46d05adf) . The timestamps for these "future" parent commits are supposed to be prior to timestamps of their children commits. Not sure what's a right way to fix the skewed timestamps, no handy command for this. Prehaps through "fossil sqlite3" direct surgery, but one needs to know how not to kill the patient in the process... Fossil hid some skeletons in the Sqlite's closet, Git just found some. Let's bring them to life :) _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
