git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Quick description of possible gitattributes system

From
APAndy Parkins <andyparkins@gmail.com>
Date
Mar 2, 2007, 08:56 UTC
Message-ID
<200703020856.35246.andyparkins@gmail.com>
In-Reply-To
<7vejo8o69o.fsf@assigned-by-dhcp.cox.net>
On Friday 2007 March 02 00:09, Junio C Hamano wrote:
[deleted lots of easily-agreed-with stuff]
> I would suggest making handler section _match_ the attribute
> names.  By "match", what I mean is to allow something like this:

I don't see that working. If it were possible to do that why would we need separate handlers and attributes? You're example is fine

> 	[handler "image/*"]
>         	pretty = "cmd display -"
But what about when I want to do this:
[handler "lossless-images-only"]
   attribute = "image/png"
   attribute = "image/gif"
   pre-commit = /bin/false

To prevent the adding of all lossless image formats? I actually can't see a time when the handler name needs referencing, so it can be anything (as long as it's unique - perhaps). If you wanted to use/encourage the attribute name - fine, but it shouldn't be required. However I think it's more sensible to name the handler after what it does than what it applies to - the applies to can change, what it does never.

The handlers are like function calls. You wouldn't want to name functions after where they were called.

Show 9 quoted lines
> > +[handler "show-images"]
> > +  attribute = image/gif
> > +  prettyfilter = pipe display -
>
> I would recommend against calling them *filter.  After all, the
> semantics of each handler action (such as input, output and
> pretty) already determine if it needs to act as a filter or data
> sink.  We do not need to say prettyfilter either; it is not even
> a filter to begin with -- it is a data sink.

That's true; I don't have any strong feelings. I just didn't like "convert" being used. Convert always sounds like something that takes one thing and makes another out of it - at the end you have two things. Filters transform one thing into another - at the end you have one thing.

Perhaps better names would be simply to name them after the operation the runs them.

 infilter = checkin
 outfilter = checkout
 prettyfilter = show
?

Is the document useful; would you like me to maintain it? I don't want to waste your time with it.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
Previous: Andy ParkinsNext: Jakub Narebski
Message 11 of 20 in “Quick description of possible gitattributes system”
  1. Quick description of possible gitattributes systemAndy Parkins, Mar 1, 2007
  2. Brian GernhardtMar 1, 2007
  3. Andy ParkinsMar 2, 2007
  4. Brian GernhardtMar 2, 2007
  5. Andy ParkinsMar 2, 2007
  6. Brian GernhardtMar 2, 2007
  7. Robin RosenbergMar 1, 2007
  8. Junio C HamanoMar 2, 2007
  9. Junio C HamanoMar 2, 2007
  10. Andy ParkinsMar 2, 2007
  11. Andy ParkinsMar 2, 2007
  12. Jakub NarebskiMar 2, 2007
  13. Linus TorvaldsMar 2, 2007
  14. Andy ParkinsMar 2, 2007
  15. Linus TorvaldsMar 2, 2007
  16. Johannes SchindelinMar 2, 2007
  17. Andy ParkinsMar 2, 2007
  18. Andy ParkinsMar 2, 2007
  19. Junio C HamanoMar 3, 2007
  20. Jakub NarebskiMar 3, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.