On 12/28/15 Dec 28 -11:57 AM, Attila Lendvai wrote:
This is the reason why I prefer 'git subtree' to 'git submodule': with
oh, git... why didn't i expect to have more than one way to implement the same thing? as opposed to e.g. having a flag that switches between the two modes of the same abstraction, both documented at the same place... maybe?
thanks for the wakeup call! :)
I just read the subtree tutorial, and I'm not convinced that this is any simpler (except that it avoids the problem of you mistakenly not ending up with your submodules empty instead of cloned.
I quote from the tutorial:
"Notice the commits near the highlighted area. See that the commits are repeated? This is git doing its magic on the pull with subtree strategy. It will bring all the commits from the other repo and will stay together with your own repo’s versions of it.
"For this reason, it’s good practice to use the “squash” option when merging changes back."
The problem of having clones not get auto-populated seems not worse than needing to do a magical incantation when you merge stuff back and forth at the cost of garbling your repo.
The submodules cause annoying quiet failures, but even when the annoying quiet failures happen, you don't end up mangling your repo.
A distributed, versioned object database is just hard. And the git UI isn't making it easier.
Best, r