On Wed, Jun 08, 2016 at 11:05:20AM -0700, Junio C Hamano wrote: > > Likewise, I'm not sure if "get" should be allowed to return contents > > that don't match the sha1. > > Yes, this is what I was getting at. It would be ideal to come up > with a way to do the large-blob offload without resorting to hacks > (like LFS and annex where "the same object contents will always > result in the same object name" is deliberately broken), and "object > name must match what the data hashes down to" is a basic requirement > for that. I meant to elaborate here more, but it looks like I didn't. One thing that an external odb command might want to be able to do is say "I _do_ have that object, but it would be expensive or impossible to get right now, so I will give you a placeholder" (e.g., you are just trying to run "git log" while on an airplane, and you would not want to die() because you cannot fetch some blob). But the right way is not to have "get" send content that does not match the requested sha1. It needs to make git aware that the object is a placeholder, so git does not do stupid things like write the bogus content into a loose object. The right way may be as simple as the external odb returning a non-zero exit code, and git fills in the placeholder data itself (or dies, possibly, depending on what the user asks it to do). One of the reasons I worked up that initial external-odb patch was because I knew that before we settled on a definite interface, we would have to try it out and see what odd corner cases came up. E.g., when do we fault in objects in a way that's annoying to the user? Which code paths need to handle "we do have this object available, but you can't see it right now, so what kind of fallback can we do?". Etc. Unfortunately I never actually did any of that testing. ;) -Peff -- 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