Re: [PATCH] Quick description of possible gitattributes system

[Brian Gernhardt <benji@silverinsanity.com>]

On Mar 2, 2007, at 7:00 AM, Andy Parkins wrote:

> On Thursday 2007, March 01, Brian Gernhardt wrote:
>
>> [attribute "image/png"]
>>     path = *.png
>>     show = "open %path%"
>> [attribute "text/plain"]
>>     path = *.c
>>     checkout = eol_to_local
>
> The problem is that this flips the relationship.  What you want to  
> do is
> assign attributes to paths.  This is assigning paths to attributes.
> What about this:
>
>   doc/*.txt = text/plain AND documentation
>
> In your system that would make

I'm sorry, I was assuming that information on what to do with each  
attribute would be in the config file while a majority of the  
attribute information was in an in-tree file.  I was actually assuming:

.gitattributes:
*.png: image/png
logo.png: logo
*.c: text/plain source

.git/config:
[attribute "image"]
    show = ...
    merge = ...

With the ability to have additional "path =" entries for *local*  
overrides/additions.  Storing the handler information in  
the .gitattributes is one of the worst things you could do, IMHO.  It  
assumes that people will have a homogenous environment to develop in,  
and that every developer want to use the same tools.  In some cases,  
this may be true (eol_lf on checking for everybody), but not in  
others.  On my Mac, I'd like to use "open" for random file types, and  
might want to use VERY different graphical merge than Linux users.   
And OS X is a fairly Unix-like environment.  Let's not even ponder  
those poor fools using MinGW.  ;-)

>> Actually, shouldn't the files also be run through the infilter to
>> check for changes caused by that, too?
>
> I don't think so.  The effect of the infilter will never be seen in  
> the
> working tree, because it's applied on git-add.  The previous  
> content with the
> old attributes are already in the repository.  However, it could be  
> that we
> would have to force those files to be marked dirty in the index  
> (this is
> already sounding bad), to force the application of the infilter on  
> next
> checkin.  Perhaps that's what you meant, and I'm being slow.

That's something like what I meant.  And it sounds bad.  Content  
changes caused by attribute changes should likely be handled by the  
user and made easy to detect instead of trying to handle it  
automatically.  So ignore my original statement on the matter.

~~ Brian