On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Is this a safe and sane thing to do, and if so why? Could you >> describe that in the log message here? > Why would fast-export try to export something that was pruned? Doesn't > that mean it wasn't reachable? Hello Junio, Hello Felipe, Actually the issue happened while using Felipe's branch with his git-remote-hg. Everything was going fine until I (or did it run automatically, I dont remember) ran git gc that pruned unreachable objects. Of course some of the branch I had pushed to the hg remote had been changed (most likely rebased). References no longer exists in the repository (cleaned by gc), but the reference still exists in mark file, as it was exported earlier. Thus the failure when git fast-export reads the mark file. Then, is it safe ? Updating the last_idnum as I do in the patch doesn't work because if the reference is the last, the number is going to be overwriten in the next run. >From git point of view, I guess it is fine. The file is fully read at the beginning of fast-export and fully written at the end. The issue is more for git-remote-hg that keeps track of matches between git marks and hg commits. The marks are going to change and be overriden. It will most likely need to read the mark file to see if a ref has changed, and update it's dictionary. One of the solution I'm thinking of, is to update the mark file with marks of newly exported objects instead of recreating it, and let obsolete references in the file. But of course that is not acceptable. Cheers, Antoine -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html