Re: [PATCH] Quick description of possible gitattributes system

From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: Brian Gernhardt <benji@silverinsanity.com>
Subject: Re: [PATCH] Quick description of possible gitattributes system
Date: Fri, 2 Mar 2007 12:00:34 +0000	[thread overview]
Message-ID: <200703021200.35069.andyparkins@gmail.com> (raw)
In-Reply-To: <CF579EA9-04AB-4B39-809F-650E611A8D6B@silverinsanity.com>

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

[attribute text/plain]
  path = doc/*.txt
  show = "open %path%"
[attribute documentation]
  path = doc/*.txt
  show = "open %path"

i.e. you've got two sections to maintain instead of one.  That's why I 
suggested:

[attributes "doc/*.txt"]
  attributes = text/plain
  attributes = documentation

I'm not really advocating that exact syntax, but I do think it's got to 
be like having a database like this:

  paths -> path-attribute-join <- attributes
  attributes -> handlers

Your method does
  path -> attribute
  attribute -> handlers

There would therefore be excessive repetition or impossible-to-specify 
connections.

> Both of these lists look right at first glance, although I think I
> prefer something simple like "show" to "prettyfilter".  And we might
> want a "reject" or "none" for merges...  Attempting to merge a bitmap
> is madness, so the system should just output a <file>-
> <head>.<extension> or similar.

I have no major concerns about any of the syntax really.  The important thing 
is that we are clear and consistent (as always).

> > + - Change of .gitattributes without change of files.
> > +   What happens when .gitattributes changes, but the files that
> > would be
> > +   affected by that change do not?  Those files really should be
> > checked
> > +   out again, to apply any new outfilter settings.
>
> 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.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com