Re: Alternates and push

> Jan Hudec <bulb@ucw.cz> writes:
> 
> > On Sat, Sep 06, 2008 at 11:06:49 -0700, Junio C Hamano wrote:
> >> Theodore Tso <tytso@MIT.EDU> writes:
> >> 
> >> > Long-standing mis-feature in git's logic in deciding what to push.
> >> > It's been reported a few times, but apparently it's hard to fix, or at
> >> > least it never hsa been fixed as far as I know.
> >> 
> >> This comes from an early (mis)design of git.
> >> [...]
> >>  * The existing alternates mechanism is not about alternate repositories.
> >>    It is about alternate object stores.  That is why each line of this
> >>    file points at "objects" directory elsewhere, not the ".git" directory
> >>    that is typically at one level above that "objects" directory.
> >> 
> >>    The fact your repository's object store points at the object store that
> >>    happens to be inside Linus's repository does not imply that Linus's
> >>    object store is associated with refs in Linus's repository in any way
> >>    (that's the early _mis_design part).
> >
> > Why is this a *mis*design? Couldn't push be fixed by redesigning it's
> > protocol along the lines of:
> >  - clients sends a list of sha1s it wants to push, from the tip down
> >  - server stops it when it sees an object it has -- this check can be done
> >    against the object store without having a ref for it.
> 
> Because your second step is *BROKEN*.
> 
> Think of a case where an earlier commit walker started fetching into that
> "server" end, which got newer commits and their associated objects first
> and then older ones, and then got killed before reaching to the objects it

> already had.  In such a case, the commit walker will *not* update the refs
> on the server end (and for a very good reason).
> 
> After that, the server end would have:
> 
>  * refs that point at some older commits, all objects from whom are
>    guaranteed to be in the repository (that's the "ref" guarantee);
> 
>  * newer commits and their objects, but if you follow them you will hit
>    some objects that are *NOT* in the repository.
> 
> Now imagine starting your broken procedure to serve clients from such a
> repository.  Your second step would cause the server to attempt to pack
> the difference from the latter classes of incomplete objects and makes the
> pack generation fail.