Linus Torvalds wrote:
It's a totally broken model. Really.
You think it solves issues, but it just creates more bugs and problems
than it solves.
Trust me. The whole point of git is that "content is the only thing that
matters", and that there isn't any other meta-data. If you break that
fundamental assumption, everything git does so well will break.
I think we've already shown that the "content matters" approach works. I
claim that the git rename tracking works better than any other SCM out
there, _exactly_ because it doesn't make the mistake of trying to track
anything but content.
The "moved + modified files" is not anything special. The current
automatic merger may not handle it, but that's not because it _can't_
handle it, it's because it tries to be simple and efficient.
And because it's so _incredibly_ fast for all the normal cases, you can
now spend some effort on figuring out renames dynamically for the few
cases where it fails. Does it do so now? No. Would adding UUID's help?
Hell no. It would be just an unmitigated disaster.
Okay, how about keeping a cache (derived from the contents) of these
types of data, to assist the merge if necessary? If it doesn't exist
when needed, it can just be created, which may take O(n) time.
-hpa
-
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
