В 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. > 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? > 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). > The problem is when the remote-helper crashes and the marks of > fast-export and the remote-helper are out of sync, and then the user > is really screwed. > This case would benefit from moving processing of GIT marks into remote helper as well. -- 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