-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
checkout: file replacing behaviour and unnecessary user interaction #2497
Comments
to be fair it is not exactly the same as
And it's def not a "bug" - it should "enhancement" and/or "research". Also, this change (and the discussion we had around |
Could you please explain what is the difference?
Why should we ignore or fail? Why don't we just behave as Git? What is the reason to change user behavior? EDITED:
Absolutely! My proposal - we should get rid of prompts whenever it is possible. |
@dmpetrov
Even
|
@shcheklein please explain the difference between
It behaves the way I described. It just handles conflicts differently depending on file that needs to be checkout. Also, it does not ask user question in any of the cases. |
It looks like this is the root cause of the miss understanding. |
ok, agreed, |
This is not related to this issue. This is an independent feature. |
Probably, I don't follow you this time. My point is that For example, non-zero exit code behavior forces you account for it when you write scripts. So, like a prompt - it won't be free in terms of scripting. It's exactly the same to my mind. Also, link to #2027 (comment) is not relevant to my mind. While in |
I did not propose overwriting uncommitted changes. I proposed getting rid of user interaction and getting to the parity with Git. Just to make it clear... In some cases, Git keeps uncommitted changes in your workspace after checkout with no aborting the command. This happens when there are no file changes between the current commit and a commit you are jumping to. In other cases - it aborts checkout. Both of the cases make sense. We should not introduce a new logic. Instead, we should reutilize users knowledge and intuition with Git. However, there might be a good reason to change the logic - I'd love to hear this.
It was a link to a specific comment (not the whole #2027) and to a discussion about user interaction in the command line. |
So, to summarize and make it clear. Your suggestion is to abort all DVC commands that potentially overwrite uncommitted changes. If that is the case, then I'm totally fine with this. This is my take on abort vs prompt:
Am I missing any other pros/cons? |
Here I'm talking only about this particular issue - prompt in In general, I only suggest avoiding to use prompt. In some cases, it should be replaced by overwriting files in other - aborting commands. This summarisation needs to be discussed separately from this issue. I've created a separate issue\question: #2498 |
@dmpetrov awesome! thanks. I would probably recommend updating the issue/ticker description to be more specific - like in your last comment. So that it won't be necessary to read it to the end (at least for me it was confusing as you can tell, haha :) ) And may be include the link to the new ticket - abort vs prompt as well. |
@shcheklein thank you for the feedback - updated the description of the current issue a bit and added more details to #2498 |
Duplication. #2801 contains more details. |
Checkout requires unnecessary user interaction if a data file was modified:
It feels like
dvc checkout
needs to be consistent withgit checkout
which does not modify changed files but just warns about it (even without risk of deleting data):Another advantage of the git-checkout is avoiding user interaction (y/n questions) which has benefits as discussed in #2027 (comment)
EDITED:
To be consistent to
git checkout
DVC should fail when a modified file in the workspace was based on an updated version of a file (compared to a file which needs to be checkout).So, two
dvc checkout
behaviors are proposed none of them with user prompt: keep a modified file in workspace or fail.The text was updated successfully, but these errors were encountered: