Jeff King <peff@xxxxxxxx> writes:
> Yeah, I think we should _always_ act on the --chmod, no matter if the
> file is racy or not, or whether it has a content change or not. I.e.,
> the race is not the problem, but rather the behavior of 4e55ed32. Your
> second proposal there sounds more like the right approach.
Yeah, you two are absolutely right. The second "git add --chmod=+x"
in
$ git add .
$ git add --chmod=+x .
should still find _all_ the non-executable paths and flip their
executable bit in the index, making them all up-to-date in the
index.
Which means that piggybacking this on the "run 'git diff' limited to
the pathspec to find the paths that needs updating" logic usually
done in "git add" can not be reused [*1*].
What was I thinking while reviewing the patch X-<. Sigh.
[Footnote]
*1* I guess we _could_, by first flipping all the regular file
blob's executable bit for paths that are inside the pathspec and
then by running "git diff" against that modified index, limited
to the pathspec, to find the paths that need to be added.
It sounds ugly, but may conceptually be cleaner. We first start
from an ideal end-result, and then re-hash what needs to be
updated to match the ideal.