Issues with new testing scripts

[Robert Goldman]

On 1/1/16 Jan 1 -6:18 AM, Kambiz Darabi wrote:
> On 2016-01-01 09:59 CET, Kambiz Darabi <darabi at m-creations.com> wrote:
> 
>> 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.

Unfortunately, right now the makefile is in the worst condition of the
whole project, because of the recent merge of minimakefile, which by its
nature was largely untestable (since exercising its functionality would
change the repository, and even the upstream repository).

Indeed, just recently, I wasn't able to use the makefile to fix my
problems with the addition of new ext/ submodules because..... the
makefile didn't work until the submodules were added.

> 
> I pushed a branch to my repo which contains the necessary changes:
> 
> https://gitlab.common-lisp.net/darabi/asdf/tree/ext-subtree
> 
> The specification of what to get where and which version is in
> ext/dependencies.lisp-expr
> 
> and
> 
> git checkout ext-subtree
> make ext
> 
> does the job.

I'm happy to consider switching to using git-subtree. It may indeed be
better.

But not until it gets some better documentation.  The discussion in the
Pro-Git book, to be honest, just makes my head hurt.  See
https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging

So, the remote repository is added as a remote for the *containing*
repository?  ASDF would have the cl-scripting as an upstream remote for
ASDF, not for a contained thing?

And this

"Then, you can merge those changes back into your master branch. You can
use git merge -s subtree and it will work fine; but Git will also merge
the histories together, which you probably don’t want."

...may mean something to the person who wrote it, but it really doesn't
mean anything clear to me.

The whole section is like this.

I am grateful to the author of this book, and I know documentation is
hard, but this simply doesn't rise to the level of an explanation.  I
suspect that the problem is that giving a real explanation would require
standing up repositories both with and without the use of git subtree
and showing by worked example what is meant by merging histories together.

Also, it seems like if you forget to use --squash merging and then push
the results to the main (cl.net) repo, you end up messing up the ASDF
repo's history in an unrecoverable way.  That seems too risky to me.
Yes, *if you notice* you can undo it with a git reset, but if you
*don't* notice, and you push, what happens then?

Best,
r