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

[Peter Stuge]

Michał Górny wrote:
> > > Shallow clone
> > > -------------
> > > - EGIT_COMMIT can only name tags (using a hash auto-forces higher mode),
>
> Limitation of git design. You can only fetch remote refs, you can't
> fetch an arbitrary hash.

Ok. Boo git.


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

Do you know if it is indeed the protocol (packs, or something else)
or the git implementation which has the limitation?


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

I think that's OK. If I've set a mode then I prefer failures over an
eclass automagically modifying my setting.


> For example, all Google Code hosted repositories do not support
> shallow mode.

It might be cool to include knowledge about this in the eclss for
telling the user about the situation, and later on perhaps even allow
setting mode per-hoster in addition to per-ebuild.


> Some projects may require single-branch mode to handle their 'git log'
> play.

That would be for the ebuilds to indicate then. Again, I prefer a
deterministic failure when what I have explicitly configured is not
possible.


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

Ah, I guess it depends on what exactly is fetched to what. I assumed
that local repos would keep remote branches similar to what git does
by default.

My point was that if that were the case, and if each mode used its
own remote name, then mix-and-match fetching couldn't break.


Thanks

//Peter