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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html