Johannes Schindelin wrote: >>>> These files which store metadata would be stored in a way that is >>>> "in another dimension" to the project files, despite being a part of >>>> the history. That means that all tools built to deal with regular >>>> files and directories will not be able to merge the changes to the >>>> attributes without special support. I think this is broken. >>>> >>>> >>> That presumes that a good way to merge attributes is to use a text >>> file merge algorithm, complete with finding diff context lines in a >>> basically unchanged order. >>> >>> >> Yes. Is that not a reasonable assumption, in the absence of anything >> more enlightened? >> > > Umm. > > It is not about _text_ file merge algorithms, but algorithms _outside of > git_! > That wasn't really the distinction I was making. It was more about, should the extra information have depth of type at the plumbing layer, or should it just appear like a regular file/directory. > If you tuck the stuff away in some obscure database where it is hard to > access, you make it more complicated and time consuming to access the data > than it needs to be to _begin with_. > Ok, but let's say for a moment that file properties are allowed, and that they are stored in the Reiser4 fashion. On filesystems that did not support this, it would be the only way to get at them - to go through the index. Unless they were also mapped to regular files, or filesystem-specific features somehow. Sam. - 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
