Re: [PATCH] Quick description of possible gitattributes system

From: Andy Parkins <andyparkins@gmail.com>
Date: Mar 2, 2007, 12:00 UTC
Message-ID: <200703021200.35069.andyparkins@gmail.com>
In-Reply-To: <CF579EA9-04AB-4B39-809F-650E611A8D6B@silverinsanity.com>

On Thursday 2007, March 01, Brian Gernhardt wrote:

Show 6 quoted lines

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

Show 5 quoted lines

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

Show 9 quoted lines

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