On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
<felipe.contre...@gmail.com> wrote:
> On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano <gits...@pobox.com> 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to