Dave Berenbaum
Dave Berenbaum
If we are writing `dvc.yaml` from dvclive, is there any downside to adding the report file to dvcignore?
> * [ ] [integrations: How to manage versions #221](https://github.com/iterative/dvclive/issues/221) > > * [ ] [`step`: Remove methods in favor of `@property`. #172](https://github.com/iterative/dvclive/issues/172) > > * [ ] [Complete examples...
Yes, listing the ref and path for now would at least create some viable workflow for how users can access the artifact (`git clone && git checkout ref && ...`).
Besides performance, my concern would be if users want to use tags the regular way and use gto, it seems like it will pollute the tags with tons of gto...
How do you see gto causing problems for typical release tags? Are you worried about conflicts or something else? One thought: using some special character to start the tag, like...
I think docs could be enough to start. The biggest problem right now is the lack of documentation, since it's unclear what to put in `gto.yaml`.
Referenced in https://github.com/iterative/dvc/pull/5282#discussion_r570719275: `Subcommand should usually be plural`
See https://github.com/iterative/dvc/discussions/5891 for `--quiet` guidelines
@skshetry Are there other issues that can be linked here?
Another guide for reference: https://primer.style/cli/