Jeff King <peff@xxxxxxxx> writes:
> ... I could see it
> if your workflow were something like "in a script, add these N files if
> they exist, but it is not an error if they don't". But I still don't
> think you would want to ignore all errors; you would want to do
> something like:
>
> $ git add $(for i in foo bar baz; do test -e $i && echo $i; done)
>
> instead. Am I missing something?
If your primary activity that happens in the work tree were:
while :
do
file=$(date +"random-%H%M%S")
>"$file"
rm -f "$file"
done
and your add were done in
while sleep 3600
do
git add $(for i in *; do test -e $i && echo $i; done)
git commit -m "hourly snapshot"
done
totally asynchronously without coordinating with what the primary activity
is doing, your "test -e && echo" can race with a concurrent "rm".
Even though I think it is an insane use pattern that we shouldn't bother
to bend too much backwards to support it, --ignore-errors were added
primarily for a similar use case (i.e. by the time we try to read it, it
is either gone or it cannot be read by the user who runs "git add"), so in
that sense it _might_ make sense to ignore all errors with the option. If
we choose to go in that direction, it would also make tons of sense to
update the documentation of the option to caution more strongly that its
use is a sign of insanity and is discouraged at the same time.
--
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