From: "Junio C Hamano" <gitster@xxxxxxxxx>
"Philip Oakley" <philipoakley@xxxxxxx> writes:
From: "Junio C Hamano" <gitster@xxxxxxxxx>
If you clone a repository, and the connection drops, the next attempt
will have to start from scratch. This can add significant time and
expense if you're on a low-bandwidth or metered connection trying to
clone something like Linux.
For this particular issue, your friendly k.org administrator already
has a solution. Torvalds/linux.git is made into a bundle weekly
with
$ git bundle create clone.bundle --all
and the result placed on k.org CDN. So low-bandwidth cloners can
grab it over resumable http, clone from the bundle, and then fill
the most recent part by fetching from k.org already.
Isn't this use of '--all' a bit of oversharing?
Not for the exact use case mentioned; k.org administrator knows what
is in Linus's repository and is aware that there is no remote-tracking
branches or secret branches that may make the resulting bundle unsuitable
for priming a clone.
OK
" I also think "--all" is a bad advice for another reason.
I do not think it is a good advice for everybody, but the thing is,
what you are responding is not an advice. It is just a statement of
a fact, what is already done, one of the existing practices that an
approach to "resumable clone" may want to help.
I was picking up on the need, for others who maybe generating clone bundles,
that '--all' may not be the right thing for them, and that somewhere we
should record whatever is deemed the equivalent of the current clone
command. This would get away from the web examples which show '--all' as a
quick solution for bundling (I'm one of the offenders there).
If I understand the clone code, the rev-list-args would be
"HEAD --branches". But I could well be wrong.
--
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html