Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > If we are deeply worried about this kind of broken connectivity, there > is another case to care about: the server can "promise" to serve > requests for some object (e.g., the tree pointed to by the server's > "master") and then decide it does not want to fulfill that promise > (e.g., that tree pointed to private key material and "master" was > rewound to avoid it). I think I've already covered that in my message (i.e. "we need to assume more than the normal Git"). In short, it is not our problem, but the "lazy-object" service's problem. If developers cannot trust the "central server", most likely owned by the organization that employs them and forces them to offload the access to these objects to the "central server", I think there is much larger problem there. > In the promises model, how we do we get a fresh > understanding of what the server wants to promise now? Yes, that is one of the things that needs to be designed if we want to officially support lazy-objects like structure. We need a way to incrementally adjust the cut-off point, below which it is the responsibility of the "other side" to ensure that necessary objects are available (on demand), and above which it is a local repository's responsibility to notice corrupted and/or missing objects.
