git clone fails due to broken link
Opened this issue · 2 comments
plavskin commented
It looks like the rapidjson github repository has moved (potentially to here), and as a result, git clone --recursive
no longer works on this repository.
ekg commented
Thanks for the catch. As a matter of current practice I'm making release
tarballs that include the submodules. We can fix this repo, but...
This is extremely old software that's full of bugs and has been superceded
by vg (vgteam/VG). You'd want to "surject" the output of vg
map/mpmap/giraffe to BAM to get the same kind of result as that provided by
glia.
…On Mon, Aug 16, 2021, 06:14 Eugene Plavskin ***@***.***> wrote:
It looks like the rapidjson github repository has moved (potentially to
here <https://github.com/Tencent/rapidjson>), and as a result, git clone
--recursive no longer works on this repository.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABDQENH6P4VKP3GPNQYLYTT5CGBZANCNFSM5CG5XH2Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
plavskin commented
Thank you so much for the suggestion! I was looking to follow part of the analysis pipeline from the 2015 1000G paper (specifically, pooling initial genotype calls from multiple callers and then re-genotyping those sites with FreeBayes), which brought me here.
Is realignment of reads around candidate variable sites still recommended before calling genotypes at those sites with FreeBayes? (The FreeBayes documentation seems to say it's not)