Jeff King <p...@peff.net> 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.