Michał Górny wrote:
> Mirror clone
> Single branch clone

Look fine.


> Shallow clone
> -------------
> - EGIT_COMMIT can only name tags (using a hash auto-forces higher mode),

Hm, why is that? This seems like an unfortunate and inconvenient
limitation which might actually reduce usefulness of shallow mode
quite severely? :\


> - changing branches may be very inefficient (since it implies
>   re-fetching all objects implied by --depth 1),

If it's the same local repo then at least in theory all existing
blobs and trees don't strictly need to be transfered, only unseen
ones and all the refs. But I'm not sure if git is so good at dealing
with this - I haven't looked at exactly how packs are structured.


> For example, if ebuilds sets EGIT_MIN_CLONE_MODE=single, and user sets
> EGIT_CLONE_MODE=shallow, this single ebuild will be fetched
> in single-branch mode. This can be used when build system operates
> on repo history and doesn't work without it.

I would prefer if I needed to allow such mode upgrades explicitly.


> When mirror or single-branch mode is used on a shallow repository,
> the repository is still marked 'shallow' even if the full history is
> available. I don't know if this wouldn't break some of 'git foo' uses
> in the checkout but that probably can't be predicted. Moreover, I don't
> know if it is safe to remove 'shallow' after doing full-fetch in mirror
> mode.

If each mode uses a different remote name (but same URL) then I don't
think anything can break.


> When single-branch or shallow mode is used on a mirror-mode repository,
> only the requested branch/tag is updated. The repository may no longer
> be correctly synced to the remote.

I think that's fine as long as only the package manager is expected
to deal with these repos. Perhaps it would be nice to have a way to
forcibly fetch using a tool in portage-utils or something. Dunno.


> That's pretty much it. Most of the stuff I've tested proof-of-concept.
> It may not work as well in the actual eclass. Any thoughts?

I think most of it sounds very good. Thanks!


//Peter

Attachment: pgpBsEdLOMVu6.pgp
Description: PGP signature

Reply via email to