Re: [PATCH/RFC 0/3] --seed as an alias for --dissociate --reference

Jeff King [off-list ref] writes:

.... Having just read through it, I think a succinct name for the
idea is "seed". That is, we seed the clone with objects from another
repository.

That's a nice name.

That thread also brought up the idea that we do not necessarily need to
seed from a local repository; we could do something like:

  1. Fetch from the seed repo into refs/seed/*

  2. Fetch from the real clone source; the fetch is optimized by the
     presence of refs/seed/*.

  3. Delete refs/seed/*. Optionally repack to drop any objects needed
     only by the seed refs.

This is awkward with the "--reference" interface, because its
implementation is publicly tied to the concept of alternates. Whereas
"--seed" is about the end result you want; we can implement it using
alternates or with a clone, depending on where the repo is located.

There are a few open issues with this series:

  1. Assuming that "seed" is a reasonable verb for this concept, is
     "--seed=<repo>" OK for the option?  Would "--seed-from=<repo>" be
     better? (Also, the response "bleh, seed is a terrible name" is
     fine, too, but only if accompanied by your own suggestion :) ).

The seed may not even have to be a repository.  A bundle file hosted
on CDN that is reachable via (resumable) wget would be another good
way to prime the well, and it would fit with the above framework
nicely.  Grab it, fetch from it into a temporary hierarchy and then
run "fetch --prune" against the repository you originally wanted to
clone from.

  2. My main goal here is making the concept easier to explain to users.
     The documentation in the third patch explains "--seed" as an alias
     for the other options, which probably isn't helping much. It might
     make sense to have a patch 4/3 that explains "--seed" first, and
     then explains "--reference" as "like --seed, but keep the
     relationship after the clone". Or maybe they should just get their
     own descriptions entirely.

  3. We can't dissociate from a specific alternate, so using "--seed"
     implies that all "--reference" options get dissociated. In this
     series, I issue a warning in that case.  But that would be easily
     solved if "--seed" used the fetch strategy described above, even
     for local clones (which would probably still be quite fast if we
     took clone's usual hard-link shortcut instead of actually fetching
     from a local clone).

I don't have particular plans to implement generic "--seed" from remotes
anytime soon. I think this takes us a step in the right direction
interface-wise, and it does introduce a succinct concept and
option.

Yes.  I like the name, the concept and the general direction.

On Wed, May 20, 2015 at 10:01:49PM -0700, Junio C Hamano wrote:

quoted

  1. Assuming that "seed" is a reasonable verb for this concept, is
     "--seed=<repo>" OK for the option?  Would "--seed-from=<repo>" be
     better? (Also, the response "bleh, seed is a terrible name" is
     fine, too, but only if accompanied by your own suggestion :) ).

The seed may not even have to be a repository.  A bundle file hosted
on CDN that is reachable via (resumable) wget would be another good
way to prime the well, and it would fit with the above framework
nicely.  Grab it, fetch from it into a temporary hierarchy and then
run "fetch --prune" against the repository you originally wanted to
clone from.

Yeah, I was just looking over the list archives for the past few months,
for things I had marked as "to read and think about later"[1]. That's
how I recalled our prior discussion on --dissociate.

Anyway, I happened upon the "prime the clone from a bundle" concept
being discussed again recently, and had the same thought. We already
treat local bundles as a possible source for fetching/cloning. Once upon
a time I had some patches that would let you clone straight from a
bundle over http (it just spooled to disk, which is not the _most_
efficient way to do it, but trying to massage the bundle straight into a
packfile[2] ends up every complex very quickly). I should resurrect those
patches.

-Peff

[1] My "think about later" mailbox has ~5000 messages in it, some of
    which are from 2010. I think I may need to just declare bankruptcy.

[2] There's that word again.