On 24/02/14 04:00 PM, Michał Górny wrote: > Dnia 2014-02-24, o godz. 21:13:15 > Peter Stuge <pe...@stuge.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? >>> - 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 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)? >>> 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
signature.asc
Description: OpenPGP digital signature
