[comex]

If it just clones the repos and removes the .git directories, then I assume it doesn't keep their commit history? So if you use e.g. `git blame` or `git log` to look at file history, you will see when changes were introduced to the parent repo, but not when/why those changes were made in the first place.

In that respect, it resembles git-subtree with --squash, but differs from git-submodule or regular git-subtree.

[ryapric]

Yep, you have it correct. I've got a note at the bottom of the README that I'm considering adding a config field to keep the .git directory, but I'm trying to keep pretty far away from git-in-git consequences/use cases. I said the same in another comment here, but I don't envision vdm becoming something that's git-specific or developmental -- it's really just intended to be a getter, not a writer, and the functionality reflects that.

Cool info though, thanks for sharing!

[lelanthran]

> I've got a note at the bottom of the README that I'm considering adding a config field to keep the .git directory, but I'm trying to keep pretty far away from git-in-git consequences/use cases.

Maybe a better approach would be to rename the `.git/` to (for example) `.vdm` in each submodule? Each `vdm` command would first rename it back to `.git`, execute the git commands needed, and then rename it back to `.vdm/`.

This gives you the ability to implement `vdm history` or similar command while still keeping the submodule invisible to the parent?

[dotancohen]

Git would then version that .vdm/ directory - the repo would grow exponentially.

[goku12]

The vdm submodule directories would probably have to be entered in the gitignore anyway. You wouldn't want to commit the submodule source files either. Won't the .git directory get excluded that way?

[fragmede]

you'd want vdm to be a superset of git commands and then alias git=vdm, or something to avoid that

[dotancohen]

No, I mean that the larger Git repo, of the main project, would version the .vdm directory.