Dnia 2014-02-24, o godz. 22:14:04
Peter Stuge <[email protected]> napisał(a):

> Michał Górny wrote:
> > > 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 don't know. I know that the protocol is sending some 'shallow <hash>'
thingies in the request but I didn't investigate too much. You can
guess what attitude people in #git have when you mention shallow
clones...

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

As soon as you do any fetch with '--depth', git marks the whole
repository shallow. Separate branches, remotes, refs don't change this.
Though '--unshallow' may help, as Alex noted. Not sure for how long,
though.

-- 
Best regards,
Michał Górny

Attachment: signature.asc
Description: PGP signature

Reply via email to