"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > One question, of course, is if one should simply keep additional > metadata around to handle this sort of situations. One could, for > example, keep a UUID for each file,...
If I am not mistaken, that is exactly what tla does. It seems to work well in practice and seem so simple (at least superficially, I have not looked deeply into the issues involved in keeping it sync with the contents and how to recover if the user ever screws up, etc.), and I can see why people find it so attractive. I myself once did. But previous argument by Linus made in a distant (in git timescale) past is now ingrained in my brain: "the additional metadata" recorded at the commit time can only help us what we envisioned in the past when the tool to record that metadata was written. If we try to "track" by contents, we can do at least the same (diff -M being able to tell renames is an example that we can get away without having a UUID) and possibly better, depending on how much effort we are willing to spend "drilling down" when we actually need to know what happened at merge time. What I found most important in that argument by Linus is that the "drilling down" algorithm can improve over time while "the additional metadata" specification is cast in stone when a commit is made. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
