diff: analyse working tree when dirty#3534
Conversation
There was a problem hiding this comment.
The change in this test is in order to actually test diff when there is no dir cache, and not intermix it with dirty repo diff.
There was a problem hiding this comment.
I have a problem with deleted, because user will not be able to commit stage file when there is no output. But I presumed that its better to just log deleted instead some ambiguous warning saying "Output is deleted but stage file still exists, so you will not be able to commit current state of file".
There was a problem hiding this comment.
deleted seems ok to me, since it's consistent with what dvc status reports for this case
file.dvc:
changed outs:
deleted: file
pared
changed the title
There was a problem hiding this comment.
deleted seems ok to me, since it's consistent with what dvc status reports for this case
file.dvc:
changed outs:
deleted: file
|
Hi! I don't completely understand this change but I'm pretty sure it requires some changes to the docs, right? |
This is an interesting topic whether or not we should stick to what is recorded in the dvc files or what is actually lying there (e.g. for cached files for any commit those would match, as cached files are determined by their hash in respective dvc-file, but for non-cached or git files/dirs it might be different), but in this case with dirty workspace we now clearly do the right thing. |
4 participants
❗ I have followed the Contributing to DVC checklist.
📖 If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here. If the CLI API is changed, I have updated tab completion scripts.
❌ I will check DeepSource, CodeClimate, and other sanity checks below. (We consider them recommendatory and don't expect everything to be addressed. Please fix things that actually improve code or fix bugs.)
Thank you for the contribution - we'll try to review it as soon as possible. 🙏
Fixes #3386