Import seems to work but commits are missing [git 2.28.0]

[gabyx]

I am questioning if this converter still works with git 2.28.0 (??)
So far as I have notices I had absolutely no problems with git v 2.27.0. All revisions have been exported and resulted in all commits in the git log. However, as I experience now (I did not see that I am newly using 2.28.0 in my conversion script)
the converter seems to export everything (at least thats what the output says) but when looking at the master branch
it seems that the exporter suddenly stopped at a certain revision (its always the same), so the my latest last 20k commits are somehow missing. I will test with 2.27.0 tomorrow, if I can successfully reproduce the initial successful conversion.

Do you know anything about that?

[gabyx]

OK. It seems that it has not to do with the git version, on one docker image running in virtual box I get all commits.
The same conversion run with the same data on the docker image on a linux server produces not all commits.
I should try to diff the --create-dump output, its 50gb...

[gabyx]

This is sooo weird.
Both conversions, the one on the linux server which is missing commits produce the same --create-dump as the conversion which is not missing commits. (checked with sha1sum)
I try now to manually import into a git repo now. If then the stuff ist still missing, there is something wrong maybe with the pipe?
Anybody might have some idea?

[ymartin59]

I propose to check what happens if option --commit-interval 100 is set.

[gabyx]

good point! thx I gonna test this...

[gabyx]

It seems that with --commit-interval 100 it works. But what is the problem behind it? Full or overflowing buffer?? from QProcess ?
The PR #117 hooks the error signal from QProcess to get some information if something weird happens... I will see if I can get any information why the commits are missing with this PR...

[gabyx]

It was probably due to the --fast-import-timeout which was not set to 6000 secs which I need. Default is 30 seconds which was I think the trouble. We should make the default to -1 or lets say 30 minutes -> Which is better to not have accidental kills... (especially when using this converter in a scripted environment)