On Sat, May 11, 2013 at 1:48 PM, Andrey Borzenkov <arvidj...@gmail.com> wrote:
> В Sat, 11 May 2013 08:57:14 -0500
> Felipe Contreras <felipe.contre...@gmail.com> пишет:
>> > 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.
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