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).
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".
Joel
--
"Vote early and vote often."
- Al Capone
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@xxxxxxxxxx
Phone: (650) 506-8127
-
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
