On Sun, Sep 07, 2008 at 11:56:42 -0700, Junio C Hamano wrote: > Jan Hudec <bulb@xxxxxx> writes: > > > On Sat, Sep 06, 2008 at 11:06:49 -0700, Junio C Hamano wrote: > >> Theodore Tso <tytso@xxxxxxx> 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 Is there really any transport that stores newer objects first? And can't be fixed to only store the objects when they are good. My proposal definitely does not need to do that (the list goes from newest to older, but the data in third step can come from oldest to newer). > 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. Yes, it would add a requirement that objects are only placed in the object store after all objects they reference, but I can't imagine good reason this couldn't be done. -- Jan 'Bulb' Hudec <bulb@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
