Junio C Hamano, Mon, Nov 26, 2007 01:30:20 +0100:
> Alex Riesen <raa.lkml@xxxxxxxxx> 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.
-
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
