Two subsequent git-push to a dataverse dataset in filetree mode break it

[mih]

It will not replace the exported files, but rather add renamed copies -- which breaks the special remote logic

[bpoldrack]

Just FTR when addressing this: IIRC this may depend on whether the previous push was "published" in between.

[mih]

In my case it was two subsequent git-push calls was nothing inbetween.

[bpoldrack]

Looking into this to figure out when and how exactly to replace instead.

[mih]

I don't think calling a replace method is the (only) fix to be made. This is happening also when nothing is changed at all. Nothing should be done in this case, not replacing X with X. I think it is worth looking into improving the file identify records. Related: #146

[bpoldrack]

Yes, I am aware. Also: We can't even replace w/o keeping track of file identifiers. (database id or persistent id, guess the latter)
Hence, need to think about how to do that best.

[bpoldrack]

This is happening also when nothing is changed at all.

Just noting an observation on this: a datalad push . --to REMOTE w/o any changes not only results in the repo itself being pushed again (under .datalad/dot_git), but in fact everything underneath .datalad, while files outside seem unaffected. Since push should figure what needs pushing, I suppose some check isn't quite right or somehow torpedoed.
Double-checking whether the leading dot issue leads to this. I think checkpresentexport might be incorrect.

checkpresentexport doesn't seem to account for the remote file's directoryLabel at all. So, apart from the leading dot issue, this would be wrong in several scenarios. I think this is one of the main points here leading to pushes where there shouldn't be any in the first place.