Re: [RFC] Making ce_path_match() more useful by accepting globs

[Alex Riesen <raa.lkml@gmail.com>]

Junio C Hamano, Mon, Nov 26, 2007 01:30:20 +0100:
> Alex Riesen <raa.lkml@gmail.com> writes:
> 
> > Junio C Hamano, Sun, Nov 25, 2007 19:03:12 +0100:
> >> Currently ce_path_match() only uses "the leading directory" match, and
> >> does not understand file globs.  These do not work:
> >> 
> >>    git diff-files 't/*.sh'
> >>    git diff-index HEAD 'xdiff/*.c'
> >>    git update-index -g 'Documentation/howto/*.txt'
> >
> > How should my scripts handle files with "*" in names?
> 
> We DO NOT CARE.
> 
> Why?
> 
> How would you handle such files from the command line session without
> git?  "ls such-*-a-file" will also show such-silly-a-file as well.

It will break existing setups. Something like

    #!/bin/bash

    git diff-files --quiet -- "$@" || do_something

will behave differently

> IOW, the user is shooting in the foot --- and at that point I am not all
> that interested in helping him.

What with? What's wrong with a name like "M*A*S*H" in your personal IMDB?

> Having said that, I would think that quoting the meta from fnmatch(3)
> like this:
> 
> 	git ls-files 'such-\*-a-file'
> 
> would work fine, just like
> 
> 	ls such-\*-a-file
> 
> would.

An existing system will still be broken.

> If "ls such-*-a-file" reports only one file,
> 
> 	git ls-files 'such-*-a-file'
> 
> would also report that file as well.
> 
> So in practice I do not see a problem.

I think I do. There is NO way to pass the filenames to git plumbing
(only the diff-, or is git update-index --stdin -z also subject to
glob expansion?) without being sure they are exactly they were on
filesystem. Quoting is just PITA for scripting.