Nicolas Pitre <nico@xxxxxxx> writes: > On Mon, 17 Dec 2007, Joel Becker wrote: > >> You may not see a case for actual corruptions, but my coworker >> updated his tree on a box with 1.5.x, then tried to work on a box with >> 1.4.x (I think 1.4.2 back then), and ended up with a tree that was >> unusable. He had to re-clone, and I think he got lucky recovering >> pending changes (probably using 1.5.x on the branches with the changes, >> as master was what got broken). > > I still claim that there wasn't any corruptions. > ... > Your allegation of corruptions is cavalier just as well. > > I'm telling you that there won't be any such corruption. Just like in > the M$ Office case, it is expected that newer versions make data > unusable by older versions at some point -- that's the inevitable side > effect of progress. This is mostly spilt milk under the bridge now, but I have to mildly disagree. If we had core.usedeltabaseoffset instead of repack.usedeltabaseoffset, and made the format negotiation in fetch-pack protocol pay attention to that variable, Joel's coworker did not have to suffer if the repository explicitly asked OFS_DELTA not to be used. 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. - 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
