Hi, On Mon, 27 Aug 2007, Sam Vilain wrote: > David Kastrup 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_! 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_. > >> As far as file properties goes, I still like Linus' idea of making > >> these files which are accessed by treating the file as a directory > >> (eg filename.txt/ACL, filename.txt/mime-type), and that approach > >> could be represented in git well. > > > > Well, at least _some_ interesting Reiser4 idea resurfaces. > > That was in there too? Man that Reiser4 manifesto read like the Naked > Lunch. It is funny. No, I mean really funny. People criticise Reiser4, and only preciously few actually have ideas as good as in Reiser4. Yes, Reiser4 was not developed as openly as it should have been. Yes, Hans was not the most diplomatic poster ever, on lkml. No, even the stupid ideas in Reiser4 are not half as stupid as mistaking the working tree for a place where only _text_ files reside. Ciao, Dscho - 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
