Re: [lmi] Tests PR 174

[Greg Chicares]

On 3/24/21 9:22 PM, Vadim Zeitlin wrote:
> On Wed, 24 Mar 2021 19:43:41 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> Please take a look at commit 593a7121f737, which may be
> GC> erroneous.
[...]
> GC> As the commit message explains, I did this:
> GC> 
> GC> $git cherry-pick e571a6e11..2769d69ba xanadu/automake-libtest
> GC> $git status                                                  
> GC> On branch master
> GC> Your branch is ahead of 'origin/master' by 28 commits.
> GC>   (use "git push" to publish your local commits)
> GC> 
> GC> Changes not staged for commit:
> GC>   (use "git add <file>..." to update what will be committed)
> GC>   (use "git restore <file>..." to discard changes in working directory)
> GC>         modified:   third_party/wx (new commits)
> GC> 
> GC> and blindly followed the "git add" advice.
> 
>  It tells you to add the files you want to commit, but you don't want to
> commit your local submodule in this situation because it hasn't been
> updated to the version in the previous commit.

Maybe they'll specialize that message for submodule changes, someday.

>  One of the confusing things about git submodules is that they, unlike
> normal files, are not updated automatically. This makes sense because
> updating a submodule is much, much more expensive than updating a single
> file, so you wouldn't want this to happen automatically when using many
> and/or big submodules (and wx is big enough already), but, again, it is
> confusing.

See note below on "much, much more expensive".

>  Instead you need to update the submodules manually whenever they are
> modified by a commit not done by you (if you had committed the submodule
> yourself, it is already at the right version). This is done using
> "git submodule update third_party/wx" command or, if you want to save on
> typing, just "git submodule update", which updates all submodules.
> 
>  Again, I know that the submodules behaviour is confusing, and I should
> have warned you about it in advance, sorry for not thinking about it. But
> at least I feel vindicated in my idea that it would be good to try a
> submodule update on this trivial change, as at least it didn't actually
> break anything for you, which wouldn't have been the case if we upgraded
> directly to wx 3.1.5.

It's not terrible once we get past the confusion.

>  So could you please revert this commit using "git revert 593a7121f" and
> push it to fix the current CI failure in clang build?

Done.

/opt/lmi/src/lmi[0]$git revert 593a7121f
[master 40c119dea] Revert "Actually update wx" (it actually didn't)
 1 file changed, 1 insertion(+), 1 deletion(-)

/opt/lmi/src/lmi[0]$git push
[...]
   0b85c1437c..40c119dea2  master -> master

/opt/lmi/src/lmi[0]$git status
On branch master
Your branch is up to date with 'origin/master'.

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)

/opt/lmi/src/lmi[0]$git submodule update
Submodule path 'third_party/wx': checked out 
'c9486f9cebb2843fdd3cb3e6433045644c456e38'

/opt/lmi/src/lmi[0]$git status          
On branch master
Your branch is up to date with 'origin/master'.
[...]
nothing added to commit but untracked files present [that's okay]

Returning to "much, much more expensive" above...okay, submodule
updates are more expensive than single-file updates; but maybe
they still belong in a hooks/post-[something] script. My reasoning
is that submodule updates should do nothing, fairly quickly, when
there's nothing to do, and in that case they really must be
idempotent. But let's experiment:

/opt/lmi/src/lmi[0]$time git submodule update
git submodule update  0.06s user 0.04s system 107% cpu 0.095 total
/opt/lmi/src/lmi[0]$time git submodule update
git submodule update  0.08s user 0.03s system 107% cpu 0.101 total
/opt/lmi/src/lmi[0]$time git submodule update
git submodule update  0.07s user 0.04s system 107% cpu 0.100 total

And after that git-status remains clean. Can I therefore conclude
that we want hooks that do 'git submodule update', because although
they may cost seconds when we need an update and must spend those
seconds anyway, their cost is negligible when there's nothing to
update?

Note: In the idempotent case, parallelism doesn't seem to help:

/opt/lmi/src/lmi[0]$time git submodule update --jobs=$(nproc)
git submodule update --jobs=$(nproc)  0.08s user 0.02s system 108% cpu 0.096 
total
/opt/lmi/src/lmi[0]$time git submodule update --jobs=$(nproc)
git submodule update --jobs=$(nproc)  0.07s user 0.04s system 107% cpu 0.104 
total
/opt/lmi/src/lmi[0]$time git submodule update --jobs=$(nproc)
git submodule update --jobs=$(nproc)  0.07s user 0.03s system 107% cpu 0.092 
total