Hi Steffen,
On Tue, 27 Jul 2021 at 23:05, Steffen Möller <steffen_moeller@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