7 ms·
Because the timestamp on the file was set back, it did not show up in any Git diffs. Is `git status` / `git diff` etc relying only on the timestamp of modified
by kiallmacinnes 7y ago
Because the timestamp on the file was set back, it did not show up in any Git diffs.
Is `git status` / `git diff` etc relying only on the timestamp of modified local files to decide if a diff is needed?
If so, that's a pretty sneaky exploit and something I'll bet many build systems are vulnerable to.
This reuse of the local clone is probably done to avoid the needed to clone from scratch. An alternative might be to have a (bare/mirror) clone maintained in `~/.cache/whatever`, then use the `--reference` flag e.g.:
git clone --reference ~/.cache/git-whatever https://github.com/whatever/whatever
- jwilk 7y ago> Is `git status` / `git diff` etc relying only on the timestamp of modified local files to decide if a diff is needed? Of course. There's no other way to implement these commands efficiently. But you don't even need to play with timestamps. You can ask git to pretend not to see the changes: git update-index --assume-unchanged password_change.cgi