Petr Baudis <pasky@xxxxxxx> writes: > Dear diary, on Tue, Oct 24, 2006 at 07:29:45AM CEST, I got a letter > where Junio C Hamano <junkio@xxxxxxx> said that... >> Petr Baudis <pasky@xxxxxx> writes: >> >> > I don't have time to code that myself right now, so I'm just tossing >> > an idea around - pushing to a directory with alternates set up should >> > avoid sending objects that are already in the alternate object database. >> >> That is probably only relevant for the first time, since >> subsequent pushes have refs from its own repository that tracks >> the tips of branches that was pushed for the last time. > > Well, I would send haves for the alternate repository anyway,... While I agree it would be an optimization if it worked, there is one conceptual problem here though, coming from old warts. It's not alternate "repository" but it is alternate object store. There is no guarantee that refs/ directory that is next to the objects/ alternate points at is related to that object store, for historical reasons (i.e. we have separate GIT_DIR and GIT_OBJECT_DIRECTORIES). So unless we declare that objects that are reachable from the refs/ *must* be fully connected in objects/ when objects/ has refs/ next to it, sending HAVEs from that refs/ can break the push, since that refs/ you are looking at may not be related to the alternate objects/ at all. I do not think it is a big restriction at all, but it is a new restriction you are adding to the repository layout. > ... You can only push if your login access is reduced to > git-shell, and something external could've set up your alternates. Ok, I was not thinking about "something external". - 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