On Mon, 17 Dec 2007, Junio C Hamano wrote: > Nicolas Pitre <nico@xxxxxxx> writes: > > > On Mon, 17 Dec 2007, Junio C Hamano wrote: > > ... > >> Instead we unconditionally said "if you are downloading with the new > >> client, we assume you would never be using older client to access that > >> repository locally, if you did so, you are screwed." > >> > >> IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT > >> native protocol use offsets to delta base when possible) could have been > >> a bit more careful in this respect. > > > > Probably. But this can hardly be called a "corruption" since nothing > > was actually lost, rather an incompatibility problem. > > It is not a corruption, but the distinction doesn't matter much to the > end user who wants to get the job done with the data right now. The > data that was made inaccessible is inaccessible. The only difference is > that it is recoverable once the user upgrades, but that may be painful, > even though it may be rewarding afterwards and worth doing so, and the > user may not be able to afford doing so right at that moment. Sure, but at some point that's something users mixing versions should be ready to cope with. We try to make it as painless as possible of course. Data corruption is usually something you just cannot recover from (unless you have backups). And if mixing different tool versions actually cause data corruption then this is a much much more serious issue and that must be avoided. So at some point the distinction must be made, and if using an old version of Git on a repo created by a new version actually produces data corruption as Joel seemed to imply, then we must really take it seriously. OTOH, compatibility issues are usually much less of a pain to fix. Nicolas - 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
