cmd: document target granularity for push/pull/etc, et al.#1384
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@jorgeorpinel Both, tbh. Was trying to find the best way to explain it here and in dvc help, then other stuff got in the way, so not enough focus for this for now. The granularity itself might not need any explanation at all, actually, because it is something that is expected, if you think about it. So I'm leaning towards just documenting that a target can be a dvc-file or a file/directory tracked by dvc (without saying that subfiles and subdirs are supported, since that seems kinda expected). |
|
Say no more, I'll take this over 🙂
Good point. Will read the cmd refs and determine this.
Actually... Can you just confirm which commands does this impact @efiop? I'm guessing checkout, fecth, pull, push, and list. |
|
@jorgeorpinel Thank you so much! 🙏 It affects push, pull, fetch, status -c(non -c one is dumb), list, get, import. |
UPDATE: Mentioned in treeverse/dvc/issues/4191 |
This comment has been minimized.
This comment has been minimized.
| | remote | `--remote` | Comparisons are made between the cache, and the given remote. Remote storage is defined using the `dvc remote` command. | | ||
| | remote | `--cloud` | Comparisons are made between the cache, and the default remote (typically defined with `dvc remote --default`). | | ||
|
|
||
| Without arguments, this command checks all stages (in `dvc.yaml` and `dvc.lock`) |
There was a problem hiding this comment.
is it union of two files? or only one of them determines the list of stages to check?
There was a problem hiding this comment.
I think it's effectively the union, from a conversation I had with @efiop once: It checks dvc.yaml to determine the stages, but later those not found in dvc.lock are skipped. Maybe a warning is printed.
There was a problem hiding this comment.
@jorgeorpinel It is not the union, we've discussed that dvc.yaml is the ultimate source of all truth. Can't say it is a union, really. Even if something is in dv.cyaml but not in dvc.lock, status will reflect that (-c or not -c)
There was a problem hiding this comment.
OK. But since stages not found in dvc.lock are then skipped, that's why I say it's effectively the union.
But in any case, that wasn't the intention of this text. It mentions dvc.lock because it talks about the hash values of the stage outputs. Updated a bit in 6ac8b0f.
There was a problem hiding this comment.
But since stages not found in dvc.lock are then skipped
if they are skipped w/o a single message then it's intersection? Only those that exist in both are checked?
There was a problem hiding this comment.
AFAIR there is a WARNING message.
| command synchronizes the workspace data with the versions specified in the | ||
| current `.dvc` and `dvc.lock` files. | ||
| This command is usually needed after `git checkout`, `git clone`, or any other | ||
| operation that changes the `dvc.lock` or `.dvc` in the workspace. It restores |
There was a problem hiding this comment.
if dvc.yaml is the source of truth for checkout then we should mention it as well probably .. or come up with some way to mention them at once like abbr DVC files abbr.
There was a problem hiding this comment.
Agree... But this one is pretty tricky. Mentioned dvc.yaml as a note for now in a919f85.
There was a problem hiding this comment.
or come up with some way to mention them at once like abbr DVC files abbr
I think we definitely need to do this and not just here but in many documents... But I'm going to extract it: see #1663
|
|
||
| - After checking out a fresh copy of a <abbr>DVC repository</abbr>, to get | ||
| DVC-tracked data from multiple project branches or tags into your machine. | ||
| - To use comparison commands across different Git commits, for example |
There was a problem hiding this comment.
I think the first one here is actually needed for the second point ?
There was a problem hiding this comment.
Yes the first one is more general, the 2nd one is a specific application of the 1st one indeed.
| | remote | `--cloud` | Comparisons are made between the cache, and the default remote (typically defined with `dvc remote --default`). | | ||
|
|
||
| Without arguments, this command checks all stages (in `dvc.yaml`) and `.dvc` | ||
| files to compare the hash values of their <abbr>outputs</abbr> (in `dvc.lock`) |
There was a problem hiding this comment.
(for stages output hashes as defined in dvc.lock)?
There was a problem hiding this comment.
"checks stages (in dvc.yaml) for output hash values as defined in dvc.lock" ? That's contradictory/ also confusing. Let me think 🧠
There was a problem hiding this comment.
Changed to
"checks all stages (defined in dvc.yaml) and .dvc files, and compares the hash values of their outputs (found in dvc.lock for stages) against"
in acf0196.
shcheklein
left a comment
There was a problem hiding this comment.
Looks great! Some final comments to check, please check it online - how does it look, any issue etc, and let's merge!
|
Sanity checks passed! (Redeployed https://dvc-landing-fix-886-jaxjy72t1y.herokuapp.com/doc/command-reference) |
Fixes #886
UPDATE: See also #1384 (comment) (could be extracted into another PR)
UPDATE: Merge #1602 after this.