Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.

From: David Kastrup <dak@gnu.org>
Date: Aug 27, 2007, 05:52 UTC
Message-ID: <85ps19a5hm.fsf@lola.goethe.zz>
In-Reply-To: <46D23C48.6060904@vilain.net>

Sam Vilain <sam@vilain.net> writes:

Show 21 quoted lines

> Dmitry Kakurin wrote:
>>> 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