Antoine Pelisse <apelisse@xxxxxxxxx> writes: > 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. You described that part very well in your proposed log message and I got it just fine. > 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. I am not sure I follow the above, but anyway, I think the patch does is safe because (1) future "fast-export" will not refer to these pruned objects in its output (we have decided that these pruned objects are not used anywhere in the history so nobody will refer to them) and (2) we still need to increment the id number so that later objects in the marks file get assigned the same id number as they were assigned originally (otherwise we will not name these objects consistently when we later talk about them). And I wanted to see that kind of reasoning behind the patch in the proposed log message, because other people will need to refer to it when they read "git log" output to understand the change. Thanks. -- 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