Re: [PATCH] Quick description of possible gitattributes system

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

On Thursday 2007, March 01, Brian Gernhardt wrote:

quoted

[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.  ;-)

quoted

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