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

[Michał Górny]

Dnia 2014-02-24, o godz. 16:10:15
Alex Xu <alex_y_xu@×××××.ca> napisał(a):

> On 24/02/14 04:00 PM, Michał Górny wrote:
> > 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.
>
> Perhaps you could have EGIT_FETCH_REF and EGIT_CHECKOUT?

I don't understand what you mean and I think you miss the point. If you
want to checkout an arbitrary commit, you need to 'fetch --depth N'
the branch it's in, with N chosen so that the requested commit will
actually be downloaded. Since we don't know how many commits we need to
download, we need to download the whole branch.

> >>> - 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.
>
> Can't you use `git fetch` as usual to download old..new commits only?
> This wouldn't help with switching branches though.

I do. Here I was referring purely to the branch switching situation.

> >> 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.
>
> Perhaps EGIT_CLONE_MODE could be a USE_EXPAND (yes, another one)?

USE flags are not supposed to be used to control internal behavior that
does not affect resulting install.

> >>> 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.
>
> git fetch --unshallow according to
> https://stackoverflow.com/questions/6802145/convert-shallow-clone-to-full-clone

Oh, yes, I forgot about that. One issue likely solved, then.

-- 
Best regards,
Michał Górny