Hi Steffen, On Tue, 27 Jul 2021 at 23:05, Steffen Möller <steffen_moel...@gmx.de> wrote:
> Hi Nilesh, > > Thank you tons for thinking along. > > It took me a bit but. Too long. The answer is that git does not lose the > sensation of a file being a git lfs reference even when you download a > tar.gz. For some reason I had expected that all genomes were truly gzipped > fasta files, but no, they were still references. Maybe I had inadvertently > transformed a few to what they point to during a first build and that is > why I then did not find the issue a bit earlier. > > The import of pristine-tar has worked after removing .gitattributes, but > then the git lfs references were still in the tarball and the upstream > branch. pristine-tar could be pushed, but then the other branches would > trigger git lfs errors when pushed to salsa. Only after having all fasta.gz > lfs files removed, the upload went smoothly and you all now find this on > https://salsa.debian.org/med-team/broad-catch > Is that really intended? We would not be able to run tests in this case since you essentially ended up repacking it , since several tests seem to be using that data. BTW, I tried to do a little solution for the lfs thingy, for it to not store "references" and committed it to my personal repository[1] Can you have a look and let me know if it looks sensible? Also, you might as well want to have a look at pristine-lfs[2] which could be interesting to use. I've attempted to use this too, please consider taking a look I admit, I'm not very used to the lfs workflow, so something could be wrong for sure. Not sure why the CI fails though -- probably it does not work fine with lfs, but just thinking of it as a ground for more ideas here :) I can clone it locally in a different space and re-produce the tarball, and I fixed a few tests (not all) -- please consider trying once and let me know [1]: https://salsa.debian.org/nilesh/broad-catch [2]: https://tracker.debian.org/pkg/pristine-lfs Nilesh