Re: [PATCH] Quick description of possible gitattributes system

From: Brian Gernhardt <benji@silverinsanity.com>
Date: Mar 2, 2007, 18:05 UTC
Message-ID: <E246B7BC-9C82-4F4E-93F0-60B3F1CA54F1@silverinsanity.com>
In-Reply-To: <200703021200.35069.andyparkins@gmail.com>

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

Show 17 quoted lines

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

Show 14 quoted lines

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