Re: [PATCH] provide advance warning of some future pack default changes

On Mon, 17 Dec 2007, Joel Becker wrote:

On Fri, Dec 14, 2007 at 09:23:38PM -0500, Nicolas Pitre wrote:

quoted

On Fri, 14 Dec 2007, Joel Becker wrote:

quoted

	The relevant message is:

Message-ID: [off-list ref]

See the paragraphs at the bottom.  The thread, started by me, begins
with:

Message-ID: [off-list ref]

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