[WIP] dvcignore: update description#494
Conversation
| - `.dvcignore` is no longer applied only on operations collecting DVC-files. | ||
| Each time DVC traverses directory, dvcignore files up to project root tree | ||
| are respected. | ||
| - ignoredd files will not be cached and preserved in any way, they will |
There was a problem hiding this comment.
it needs more details on what does "preserved" means. It's not clear. For example, when we remove outputs do we skip ignored files or remove them as well? It worth describing and mentioning these edge cases. And give examples below.
There was a problem hiding this comment.
I agree, I think I should remve the preserved part. The most important thinkg about this point is that ignored files will not be cached. Ill inkclude removing edge case in new point.
| be non-existent for DVC. Its worth to remember that, especially when ignoring | ||
| files inside DVC-handled directories. | ||
| - ignoring files inside directory dependencies under DVC control means that | ||
| this dependency has changed, as if ignored files were deleted, so commiting |
There was a problem hiding this comment.
is it about dependency or outputs as well?
| - ignoring files inside directory dependencies under DVC control means that | ||
| this dependency has changed, as if ignored files were deleted, so commiting | ||
| "new" version of dependency might be required. | ||
| - If DVC will stumble upon `.dvcignore` file inside dependency directory, it |
There was a problem hiding this comment.
is it about dependency or outputs as well?
shcheklein
left a comment
shcheklein
left a comment
There was a problem hiding this comment.
Good stuff!
Some changes are needed (see comments) + we need to update examples probably.
pared
changed the title
| - You need to create `.dvcignore` file. | ||
| - Populate it with [patterns](https://git-scm.com/docs/gitignore) that you would | ||
| like to ignore. | ||
| like to ignore |
| is advised to use it in cases described in the first paragraph, when amount of | ||
| files in tree of repository directory causes performance issues. | ||
|
|
||
| - Ignored files will not be cached, they will be non-existent for DVC. It's |
There was a problem hiding this comment.
cached -> taken under DVC control, or saved. cached is an internal term more or less. It's always better to explain stuff in terms that come from the end-user world, not from the internal implementation.
There was a problem hiding this comment.
Lets meet halfway: saved in cache
shcheklein
left a comment
shcheklein
left a comment
There was a problem hiding this comment.
Good stuff. Check my comments and would be great to put more examples?
Yes, Ill introduce them. |
shcheklein
left a comment
shcheklein
left a comment
There was a problem hiding this comment.
Good stuff, still some changes are required.
| @@ -18,26 +19,126 @@ provide similar functionality as `.gitignore` files provide for `git`. | |||
| - Each line should contain only one pattern; | |||
| - During execution of commands that traverse directories, DVC will ignore | |||
| matching paths; | |||
There was a problem hiding this comment.
traverse directories - it's not only about dirs, right?
There was a problem hiding this comment.
Ignore is not only about dirs, but it works only during traversing of dirs :)
| @@ -18,26 +19,126 @@ provide similar functionality as `.gitignore` files provide for `git`. | |||
| - Each line should contain only one pattern; | |||
There was a problem hiding this comment.
please, use . instead of ; at the end of each item
There was a problem hiding this comment.
Ok, but I did it to match changes introduced for unification of bullet lists. Isn't it the way we are handling bullet lists now?
There was a problem hiding this comment.
Nope, we're avoiding ; moving forward (: Refer to #491 (comment)
shcheklein
left a comment
shcheklein
left a comment
There was a problem hiding this comment.
almost there :) just a few comments, typos and small improvements.
|
thanks! |
3 participants
IMPORTANT NOTES (please read, then delete):
Have you followed the guidelines in our
Contributing Documentation?
The PR title should start with "Fix #bugnum: " (if applicable), followed by a
clear one-line present-tense summary of the changes introduced in the PR. For
example: "Fix #bugnum: Introduce the first version of the collection editor.".
Please make sure to mention "Fix #bugnum" (if applicable) somewhere in the
description of the PR. This enables Github to link the PR to the corresponding
bug.
Fixes #485