Jonathan Tan <[email protected]> writes: > One possibility to conceptually have the same thing without the overhead > of the list is to put the obtained-from-elsewhere objects into its own > alternate object store, so that we can distinguish the two.
Now you are talking. Either a separate object store, or a packfile that is specially marked as such, would work. "Maintaining a list of object names in a flat file is too costly" is not a valid excuse to discard the integrity of locally created objects, without which Git will no longer be a version control system, and your "We have to trust the sender of objects on the other side anyway when operating in lazy-objects mode, so devise a way that we can use to tell which objects we _know_ the other side has" that leads to the above idea is a good line of thought. > I mentioned > this in my e-mail but rejected it, but after some more thought, this > might be sufficient - we might still need to iterate through every > object to know exactly what we can assume the remote to have, but the > "frontier" solution also needs this iteration, so we are no worse off. Most importantly, this is allowed to be costly---we are doing this not at runtime all the time, but when the user says "make sure that I haven't lost objects and it is safe for me to build further on what I created locally so far" by running "git fsck".
