Issues with new testing scripts

[Robert Goldman]

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