Howdy, Discovered a potential bug with fossil's ability to import git repositories. This issue appears to happen when a git repository has a commit that removes all files from it. What happens is that fossil 'skips' the changeset with all files removed in it, resulting in a dangling ancestor.
Note I am attaching a compressed git fast-export stream from a git repository I created to illustrate the bug. How to reproduce using the attached fast-export stream: 1) gunzip -c example.fi.gz | fossil import --git example.fossil 2) fossil ui example.fossil 3) Select 'Timeline' You will see that 'trunk' goes up until it hits the revision before the deletion of all files. Then the revision that adds files back again is created on a parallel unnamed branch with a dangling ancestor. As a side effect of this, if you attempt to open a changeset on the 'dangling' branch and edit it via the UI, you are greeted with the following: fossil(81780,0x7fff7a242310) malloc: *** error for object 0x10db30790: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug This behavior was seen on Fossil 1.28. Note I checked the fast-export stream and the 'delete' commit is there, so something is eating the commit. As a side note, is there any way to recover from this scenario? I've got a personal 16 year old repository that went from CVS -> Subversion -> Fossil by way of git that has the 'dangling' commit and I'm unable to edit the starting point of the dangling commit due to the pointer error above. If you require any further information or want me to create a ticket, let me know. Cheers! -- Christopher M. Fuhrman cfuhr...@pobox.com
example.fi.gz
Description: GNU Zip compressed data
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
