"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

Reply via email to