Hi, On Tue, 28 Aug 2007, Sam Vilain wrote: > Johannes Schindelin wrote: > >>> 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. Hehe, I was a little confused by your answer... I guess I did not respond to _your_ statement, but the not-quite-clever-one you were responding to. > > 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. Happily, file properties as well hidden as these have _no_ _place_ in source code that needs to be tracked. 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
