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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to