Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > "Imported" objects must be in a packfile that has a "<pack name>.remote" > file with arbitrary text (similar to the ".keep" file). They come from > clones, fetches, and the object loader (see below). > ... > A "homegrown" object is valid if each object it references: > 1. is a "homegrown" object, > 2. is an "imported" object, or > 3. is referenced by an "imported" object. Overall it captures what was discussed, and I think it is a good start. I doubt you want to treat all fetches/clones the same way as the "lazy object" loading, though. You may be critically rely on the corporate central server that will give the objects it "promised" when you cloned from it lazily (i.e. it may have given you a commit, but not its parents or objects contained in its tree--you still know that the parents and the tree and its contents will later be available and rely on that fact). You trust that and build on top, so the packfile you obtained when you cloned from such a server should count as "imported". But if you exchanged wip changes with your colleages by fetching or pushing peer-to-peer, without the corporate central server knowing, you would want to treat objects in packs (or loose objects) you obtained that way as "not imported". Also I think "imported" vs "homegrown" may be a bit misnomer; the idea to split objects into two camps sounds like a good idea, and "imported" probably is an OK name to use for the category that is a group of objects to which you know/trust are backed by your lazy loader. But the other one does not have to be "home"-grown. Well, the names are not that important, but I think the line between the two classes should not be "everything that came from clone and fetch is imported", which is a more important point I am trying to make. Thanks.
