Issues with new testing scripts

[Kambiz Darabi]

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. 

> 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