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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sam Vilain <sam@xxxxxxxxxx> writes:

> 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
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux