🇳🇱
@a1batross Id imagine the big problem being that it has no way of knowing if the repo changed since the first clone started and failed. Normally the server would handle that by temporarily cacheing a complete copy of the repo whent he clone starts but it discards that cache the second the connection drops. someone may have changed the repo in the time it akes you to resume.
@a1batross In theory its possible even under ssh, the problem is it would require a significant change to the standard around a clone
cat chjara This is exactly what I was going to say, you can already do it incrementally by just pulling down at depth=1 and then expand the depth incrementally till you have a full clone. But this would be slow as balls which is the very reason clone doesnt work this way.
I'd imagine clone resuming isnt really worth the effort considering that it should be rarely needed.
GIT repos are by design suppose to be small. The first rule of git repos is you only check non-binary small size content (ideally). So if you are cloning a repo and the repo is of a particularly large size then you are probably misusing GIT int he first place.
True, but that is probably at the uppermost limit of what any reasonable repo can be.. and keep in mind we are talking about a very hold and very large project, unlike the vast majority of projects... Still 100 MB in todays day and age of broadband isnt really that big IMO.
