# Is it possible to use DVC without knowing how it works internally?

**URL:** <https://discuss.dvc.org/t/is-it-possible-to-use-dvc-without-knowing-how-it-works-internally/195>\
**Category:** Development\
**Created:** [August 12, 2019, 10:31am UTC](https://discuss.dvc.org/t/is-it-possible-to-use-dvc-without-knowing-how-it-works-internally/195 "2019-08-12T10:31:08Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![dashohoxha](https://yyz1.discourse-cdn.com/flex035/user_avatar/discuss.dvc.org/dashohoxha/32/45_2.png) [@dashohoxha](https://discuss.dvc.org/u/dashohoxha)\
**Post date:** [August 12, 2019, 10:31am UTC](https://discuss.dvc.org/t/is-it-possible-to-use-dvc-without-knowing-how-it-works-internally/195/1 "2019-08-12T10:31:09Z")

</div>

I am wondering, when we do a `dvc init`, `dvc add` etc. why don’t we do an automatic `git add` and `git commit` as well (with a suitable message)?

In case there are some local changes on the repo, it is possible to do a `git stash` before and a `git stash pop` after these changes, so that they don’t mess with other changes.

This question is also related somehow to another question.  
I see all over the docs that the internals of how DVC works are explained everywhere. I just wonder, is it possible to use DVC without knowing how it works internally, without having to explain it to the users, similar to `git`?

Of course, knowing the internals has its own advantages (in understanding better the commands and their options, making better decisions, etc.) but I think that it should not be a must for using DVC.

**Note:** Sorry if I am raising questions that have been discussed and resolved before, but it is much easier to ask than to search all the docs and previous discussions.

---

<div class="post-metadata">

**Author:** ![Paffciu](https://avatars.discourse-cdn.com/v4/letter/p/d07c76/32.png) [@Paffciu](https://discuss.dvc.org/u/Paffciu)\
**Post date:** [August 12, 2019, 11:35am UTC](https://discuss.dvc.org/t/is-it-possible-to-use-dvc-without-knowing-how-it-works-internally/195/2 "2019-08-12T11:35:43Z")

</div>

At some point we have been researching if its possible to introduce more git hooks. Regretfully capabilities of git hooks are not enough for our use case. Thats why there is idea to introduce feature that would automatically handle git calls. [Here](https://github.com/iterative/dvc/issues/1551) is some context. I think we should create issue for `autoscm` feature.

---

<div class="post-metadata">

**Author:** ![shcheklein](https://yyz1.discourse-cdn.com/flex035/user_avatar/discuss.dvc.org/shcheklein/32/173_2.png) [@shcheklein](https://discuss.dvc.org/u/shcheklein)\
**Post date:** [August 12, 2019, 3:51pm UTC](https://discuss.dvc.org/t/is-it-possible-to-use-dvc-without-knowing-how-it-works-internally/195/3 "2019-08-12T15:51:26Z")

</div>

@dashohoxha good questions!! no need to be sorry at all.

> why don’t we do an automatic `git add` and `git commit` as well (with a suitable message)?

People have a lot of different opinions on when and how commits should be created. It’s not about stash only, it’s about being in the right branch, being up to date with the upstream, etc. Any edge case and it will require significant effort to recover. So, it’s just to keep it simple and less opinionated I  
believe.

> knowing the internals

It’s totally possible to do this, that’s why we use expandable sections a lot. It’s still very beneficial to learn how DVC-files are organized, for example. Similar to Git, it gives just another level of ability to use tool, understand its options, etc.

---

<div class="post-metadata">

**Author:** ![dashohoxha](https://yyz1.discourse-cdn.com/flex035/user_avatar/discuss.dvc.org/dashohoxha/32/45_2.png) [@dashohoxha](https://discuss.dvc.org/u/dashohoxha)\
**Post date:** [August 12, 2019, 4:55pm UTC](https://discuss.dvc.org/t/is-it-possible-to-use-dvc-without-knowing-how-it-works-internally/195/4 "2019-08-12T16:55:34Z")

</div>

> [@shcheklein](#):
>
> It’s totally possible to do this, that’s why we use expandable sections a lot.

If we tell the user: “Now do `git add Posts.xml.dvc data/.gitignore`”, then we also have to explain them why, how DVC manages data files internally, etc. If we do it automatically, followed by an auto-commit, then probably the user does not have to concern himself with the internal details (which may also change time after time, if we realize that there are better or more efficient ways to implement things). In this case the user can focus only on the high level steps of DS/ML processing. This is a kind of encapsulation.

> [@shcheklein](#):
>
> People have a lot of different opinions on when and how commits should be created. It’s not about stash only, it’s about being in the right branch, being up to date with the upstream, etc. Any edge case and it will require significant effort to recover. So, it’s just to keep it simple and less opinionated I

I trust that you are right about this, but I still cannot conceive how it can go wrong. Maybe because I am not well-versed on DS/ML processes and workflows (I would need to see some concrete cases/examples where this can fail hopelessly, without being able to prevent or repair it).

What if there is a configuration option like `auto-commit=True`, which users can disable if they wish? In this case it will do auto-commit by default, unless there is a complex situation where user does not want this to happen?

---

<div class="post-metadata">

**Author:** ![jorgeorpinel](https://yyz1.discourse-cdn.com/flex035/user_avatar/discuss.dvc.org/jorgeorpinel/32/46_2.png) [@jorgeorpinel](https://discuss.dvc.org/u/jorgeorpinel)\
**Post date:** [August 12, 2019, 6:48pm UTC](https://discuss.dvc.org/t/is-it-possible-to-use-dvc-without-knowing-how-it-works-internally/195/5 "2019-08-12T18:48:42Z")

</div>

@dashohoxha have you noticed the `dvc install` command? It partially does what you suggest.

> **[install](https://dvc.org/doc/command-reference/install)**
>
> Open-source version control system for Data Science and Machine Learning projects. Git-like experience to organize your data, models, and experiments.
