<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 25, 2017 at 3:32 PM, David Thompson <span dir="ltr"><<a href="mailto:david.thompson@kitware.com" target="_blank">david.thompson@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Marcus,<br>
<span class=""><br>
> That is odd, I was interested, and just tried cloning<br>
><br>
> $ time git clone <a href="https://gitlab.kitware.com/ben.boeckel/cmb-lfs-test.git" rel="noreferrer" target="_blank">https://gitlab.kitware.com/<wbr>ben.boeckel/cmb-lfs-test.git</a><br>
> real    0m39.754s<br>
</span><span class="">> $ time git lfs clone <a href="https://gitlab.kitware.com/ben.boeckel/cmb-lfs-test.git" rel="noreferrer" target="_blank">https://gitlab.kitware.com/<wbr>ben.boeckel/cmb-lfs-test.git</a><br>
> real    0m18.448s<br>
><br>
> This is with git 2.13.3<br>
</span><span class="">> Definitely faster, and easier to follow output, but both pretty fast from 21 on a desktop Linux machine.<br>
<br>
</span>I am pretty sure it has a lot to do with your proximity to the data. At KRS, it took<br></blockquote><div><br></div><div>Totally agree, just trying to add some data points. It would be good to compare with GitHub too as we would both be remote - at best you can saturate KHQ's 150Mbps connection, but it could be far worse that that too.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  git clone, Ben's test repo      21m32s<br>
  git lfs clone, Ben's test repo   6m36s<br>
  git clone, CMB test-data repo    2m28s<br>
<br>
This is git 2.11.0 on macos Sierra. I also installed homebrew git (2.13.3) and got a similar time for "git lfs clone" (6m49s).<br></blockquote><div><br></div><div>If I understand correctly, Ben was saying newer git makes git clone perform nearly as well as git lfs clone. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We are planning to move ahead with git-lfs but will prune the larger, unused input datasets by not adding them to the repo. If we need large data (examples or benchmarking) a separate repo is an option.</blockquote><div><br></div><div>Sounds good, we will probably use this approach for Tomviz, but likely on GitHub with their 1GB limit on LFS data size. We haven't gotten to it yet, so certainly interested in new findings for an already quite large data repository.</div><div><br></div><div>Marcus <br></div></div></div></div>