Issues with new testing scripts

[Robert Goldman]

On 12/31/15 Dec 31 -5:46 AM, Kambiz Darabi wrote:
> On 2015-12-29 01:58 CET, Robert Goldman <rpgoldman at 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. 

Can you explain that stuff about needing to squash? I read the subtree
tutorial and that discussion just seemed like gibberish to me.  Very far
from clear.  Maybe it's easier than the discussion made it seem.  As I
read it, it seemed to be saying that if you didn't remember to do
--squash at the right times you would end up with a repo clogged with
duplicate commits.

If that's the case...ugh.  But perhaps it was just a bad explanation?
Or does your subtree add expression above ensure that the squashing
becomes the default?

If we could figure this out maybe subtrees would be easier.  But if you
have to remember to squash every time, forget it....

> 
>> 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.

FWIW, the subversion externals seem *much* easier to use.  But
subversion is centralized, which makes this problem much easier, so it's
not a fair comparison.


Thanks,
r