On 2015-12-29 01:58 CET, Robert Goldman rpgoldman@sift.net wrote:
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 complete magical incantation reads:
git subtree add --prefix=ext/alexandria --squash https://gitlab.common-lisp.net/alexandria/alexandria.git master
and to update it to the lastest master, replace 'add' with 'pull'.
The submodules cause annoying quiet failures, but even when the annoying quiet failures happen, you don't end up mangling your repo.
The problem with submodules is that every single person who checks out the repo is concerned with it, whereas git subtree has to be performed only by one single person and for all others it just works without them even knowing that there is a 'subtree' being used somewhere.
A distributed, versioned object database is just hard. And the git UI isn't making it easier.
I use VCS since 1989 and have never had an easier way of tracking vendor branches than this.
Cheers
Kambiz