Jan Hudec <bulb@ucw.cz> writes:

quoted text
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html