On Mon, 17 Dec 2007, Joel Becker wrote: > On Fri, Dec 14, 2007 at 09:23:38PM -0500, Nicolas Pitre wrote: > > On Fri, 14 Dec 2007, Joel Becker wrote: > > > The relevant message is: > > > > > > Message-ID: <7vveaindgp.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> > > > > > > See the paragraphs at the bottom. The thread, started by me, begins > > > with: > > > > > > Message-ID: <20070910205429.GE27837@xxxxxxxxxx> > > > > OK. From those emails Junio forwarded to me, I don't see any case for > > actual _corruptions_. Git does indeed refuse to work with unknown pack > > index or unknown objects in a pack. Really old versions were not overly > > clueful as to why they refused to work, but they should never corrupt a > > pack which, for all purposes, is always read-only anyway. > > 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. Just for fun, just edit some document with Microsoft Office 95, then open the same document with Office 2007 and save it with default settings. Now try to open it back with Office 95. It won't work. Does that mean that the document got corrupted? > My point is not that change is always bad, but that we should > really look forward to what we're doing, and that "it's in the release > notes" is not sufficient if an older git gives an incomprehensible error > or a silent problem. I was responding to the cavalier statement "well, > it's in the release notes, so don't worry about older versions". 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. And we cannot always anticipate what kind of incompatibility will be worth making in the future, so it is hard to come with proper error messages in all cases today. Recent enough Git versions do suggest upgrading when they refuse to access repositories though, and later Git versions can be configured to remain compatible with old Git versions. And we also document it. And when you still cannot figure it out on your own, then there is that free support available on a public mailing list, and even an IRC channel. So I don't see how we could do better in that regard. Carving the repository format in stone to keep ancient versions working forever is _not_ a solution. 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
