Re: [lmi] Tests PR 174 (was: Can't get GUI test to run for pc-linux-gnu)

[Greg Chicares]

On 3/24/21 7:43 PM, Greg Chicares wrote:
[...]
> Please take a look at commit 593a7121f737, which may be
> erroneous. As the commit message explains, I did this:
> 
> $git cherry-pick e571a6e11..2769d69ba xanadu/automake-libtest
> $git status                                                  
> On branch master
> Your branch is ahead of 'origin/master' by 28 commits.
>   (use "git push" to publish your local commits)
> 
> Changes not staged for commit:
>   (use "git add <file>..." to update what will be committed)
>   (use "git restore <file>..." to discard changes in working directory)
>         modified:   third_party/wx (new commits)
> 
> and blindly followed the "git add" advice. Now it looks
> like I should have ignored it...and instead have used
> "git restore" to discard it? Is that the proper way to
> get git-status to report that everything's clean?

Well...I rebuilt, in an experimental chroot, with lmi HEAD
as it now stands, and it produced a wx dll with suffix
"-6cdaedd4.dll", which is the old SHA1, so my "git add"
was definitely wrong, and I have to revert it.

After reverting 593a7121f7373b2900 locally, upon
rebuilding I see:

  + git submodule update --jobs=32 --recursive --init
  Submodule path 'third_party/wx': checked out 
'c9486f9cebb2843fdd3cb3e6433045644c456e38'

which looks like what is intended...so I should revert
593a7121f7373b2900 and push that reversion.

But how can we prevent this in the future?

Should we set
  git config --global submodule.recurse true
as this article
  
https://stackoverflow.com/questions/4611512/is-there-a-way-to-make-git-pull-automatically-update-submodules
suggests? One comment argues against it this way:

| a submodule is another repository and should not be affected by
| commands executed in the parent-repository by default. this is
| a kind of design-decision by the git-developer.

and another says:

| This is a dangerous setting if you care about local changes in
| the submodule. It seems to do the equivalent of --force, which
| will discard any changes in the index or working tree, and it
| will happily let you lose track of local commits (you'll have
| to resort to reflog)!

But that sounds like exactly what Kim and I would want: we're
unlikely to make local changes ourselves. You're likely to do
that, but after you push, the changes that were local from your
POV become remote by the time we pull them. We'd lose track of
our own local commits, of which there will probably never be any.

Yet another comment says:

| This answer is highly deceptive. Even when used with git pull,
| rather than git fetch, this option only makes the fetching
| recursive. It will not change what commit is checked out in the
| submodules at all. So git submodule update is still necessary

which makes it sound like 'submodule.recurse' doesn't solve
the problem for us.

However, is it bad for you if I put that in some script that
you might run? I gather that "the equivalent of --force" above
might cause you problems.

Is the optimal answer then to add two hooks:
  hooks/post-checkout
  hooks/post-merge
both of which contain the following?
  #!/bin/sh
  git submodule update --init --recursive