From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Fri, 23 Sep 2011 10:38:11 GMT
Subject: Re: How to use git attributes to configure server-side checks?
Message-ID: <4E7C6193.2020201@alum.mit.edu>
In-Reply-To: <m3vcskqjcv.fsf@localhost.localdomain>

On 09/23/2011 12:54 AM, Jakub Narebski wrote:
> There is a slight problem from the UI point of view of git-check-attr,
> namely that there are _three_ pieces of information: a place to read
> .gitattributes from (working tree, index, commit), list of attributes
> to check (or --all) and list of files (list of paths).  You can use
> "--" to separate _two_ pieces of information.

An alternative would be to accept <rev>:<path>, :<n>:<path>, and :<path>
in addition to simple <path>.

I also just remembered that currently the paths passed to
git-check-attr, git_check_attr(), and git_all_attrs() do not have to
correspond to existing objects; the paths are compared as strings.
Presumably we should retain this aspect of the behavior even if a
revision or tree is specified explicitly.

There are other problems in the UI of git-check-attr:

1. Its "-z" option affects how standard input is interpreted; there is
no way to cause the output to be generated with NUL separators.

2. Its output does not distinguish between the special statuses
unspecified/unset/set and possible string values
"unspecified"/"unset"/"set".

Maybe a --porcelain option could be used to overcome these shortcomings.

If necessary we could deprecate "git check-attr" and implement an
improved command ("git get-attr"?) that starts from a clean UI slate.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/