Issues with new testing scripts

[Kambiz Darabi]

Happy New Year,

On 2015-12-31 16:12 CET, Robert Goldman <rpgoldman at sift.net> wrote:

> 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:
>> 
>>> 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?

My command above does contain the '--squash' option. The git-subtree
author just chose the wrong default: usually, you are not interested in
seeing each and every commit in the external repo.

But again, if you do the wrong thing, it's just a matter of:

git reset --hard HEAD~2
git subtree add/pull --squash ...

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

IMO such commands should be automated with a makefile entry, so you
wouldn't have to remember the --squash option.

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

I remember there was also some incantation with svn propset/propget, you
had to commit separately if you changed something in the vendor
branch. And we also had problems with tagging and branching which I'm
happy not to remember any more.

Cheers


Kambiz