Re: [gentoo-dev] RFC: git-r3, additional clone types

[Michał Górny]

Dnia 2014-02-24, o godz. 21:13:15
Peter Stuge <peter@×××××.se> napisał(a):

> Michał Górny wrote:
> > 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? :\

Limitation of git design. You can only fetch remote refs, you can't
fetch an arbitrary hash. And since we don't download the whole history,
we can't use a hash that was past 'depth' of the branch/tag clone. So
in order to use an arbitrary hash, we actually have to download
the history.

> > - 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.

It's not good at all. In fact, if you try to update a shallow clone
with 'git fetch --depth 1', it's going to refetch all the objects
(while plain 'git fetch' only downloads new objects). It's just another
limitation of protocol that we can't do much about.

> > 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.

That sounds like a lot ebuilds failing, requesting you to explicitly
change the mode. For example, all Google Code hosted repositories
do not support shallow mode. Some projects may require single-branch
mode to handle their 'git log' play.

> > 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.

Remote names are just aliases for URIs. They are meaningless and we
don't even bother using them. Well, actually I may add 'git remote'
since that doesn't hurt but it's a completely unrelated topic.

-- 
Best regards,
Michał Górny