Shawn Bohrer [off-list ref] writes:
Nope the problem Johannes Sixt was having was that he mistakenly ran
git clean -n /*foo
Now that isn't what he meant to do, but I figured it might be possible
that someone has their whole filesystem in a git repository, or maybe
is using some sort of chroot on their repository. Your malformed
paths guess is probably much more likely to occur.
That is not a user error from the syntax point of view (although
it might be from the semantics point of view). I think the
caller of the excluded() function (that is probably somewhere in
builtin-clean.c -- I did not check) is responsible for not
supplying such a path to the called function.
Junio C Hamano schrieb:
Shawn Bohrer [off-list ref] writes:
quoted
Nope the problem Johannes Sixt was having was that he mistakenly ran
git clean -n /*foo
Now that isn't what he meant to do, but I figured it might be possible
that someone has their whole filesystem in a git repository, or maybe
is using some sort of chroot on their repository. Your malformed
paths guess is probably much more likely to occur.
That is not a user error from the syntax point of view (although
it might be from the semantics point of view). I think the
caller of the excluded() function (that is probably somewhere in
builtin-clean.c -- I did not check) is responsible for not
supplying such a path to the called function.
The "problem" is not only with git-clean, but also in others, like
git-ls-files. Try this in you favorite repository:
$ git ls-files -o /*bin
The output does not make a lot of sense. (Here it lists the contents of
/bin and /sbin.) Not that it hurts with ls-files, but
$ git clean -f /
is basically a synonym for
$ rm -rf /
-- Hannes