On Sat, May 11, 2013 at 1:48 PM, Andrey Borzenkov <arvidjaar@xxxxxxxxx> wrote: > В Sat, 11 May 2013 08:57:14 -0500 > Felipe Contreras <felipe.contreras@xxxxxxxxx> пишет: > >> > >> > The problem seems to be that git fast-export updates marks >> > unconditionally, whether export actually applied or not. So next time >> > it assumes everything is already exported and does nothing. >> > >> > Is it expected behavior? >> >> Indeed, this is the way it currently works, and it's not easy to fix. >> We would need some way to make fast-export wait until we know the exit >> status of the remote helper, and then tell it when it failed, so the >> marks are not updated. >> > > One possibility would be to omit *export-marks and manage GIT marks in > remote helper as well. Helper would then update synchronously both GIT > and BZR marks if no errors were detected. Or even better, it could > update just those commits that had been successful. That would need to change the whole architecture, because right now the remote helpers are agnostic of Git SHA-1s. >> However, the way remote-bzr/hg work is that the commits are still >> there anyway. So if you merge the next time you push those commits are >> already converted, so it's not a problem if fast-export is not >> exporting them again. >> > > As I understand bzr commit ID is stable. What happens if we try to > commit the same ID second time? It's skipped, because it's already converted. >> So even though it's not ideal, it should work. >> > > I'm more concerned about transport errors. Any network glitch during > push renders you repository unusable (at least, without much efforts). No, it doesn't. If the remote-helper fails gracefully, the bzr revisions are converted and stored in the bzr repo, even if they were not pushed to the remote. So it's OK if fast-export never exports them again; we already have them. Cheers. -- Felipe Contreras -- 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