Sam Vilain [off-list ref] writes:
Dmitry Kakurin wrote:
quoted
quoted
A tree that has .gitattributes (and I am assuming in the longer
term you can use "ignore" and "precious" in .gitattributes
instead of using .gitignore) POINTS TO A BLOB already, so what
you are saying does not add anything to what we already have,
other than that you are renaming .gitattributes to "META ENTRY".
Almost true! The difference is: META BLOBS are not created as files in
the workspace (not during checkout, not ever).
In order to edit it you'd have to use 'git meta' command.
So once again, there is only one place to check for metadata - the index.
Can I just chime in here and express my distaste for this idea, on
several grounds, but the summary is that svn does it this way, so it
must be wrong.
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.
And I don't see that this is a sensible merge strategy at all. No
matter where the attributes are stored, whether in a file or somewhere
else, any useful merge strategy would require an algorithm quite
different from the currently used one.
Now this might be a case for pluggable merge strategies: after all,
there might be non-git related files with similar unordered per-line
merge semantics, or files expressing some information about files.
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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup wrote:
quoted
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?
quoted
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.
Sam.
Sam Vilain [off-list ref] writes:
David Kastrup wrote:
quoted
quoted
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?
Is that a trick question? My comment was exactly about not throwing
away the information ("This is not arbitrary text but talks about the
files in our tree.") that would make for more enlightened use.
--
David Kastrup
Hi,
On Mon, 27 Aug 2007, Sam Vilain wrote:
David Kastrup wrote:
quoted
quoted
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_.
quoted
quoted
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