Re: [lmi] Tests PR 174

[Greg Chicares]

On 3/24/21 10:24 PM, Vadim Zeitlin wrote:
> On Wed, 24 Mar 2021 21:56:56 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> GC> Is the optimal answer then to add two hooks:
> GC>   hooks/post-checkout
> GC>   hooks/post-merge
> GC> both of which contain the following?
> GC>   #!/bin/sh
> GC>   git submodule update --init --recursive
> 
>  None of these hooks is used after cherry-pick, so this wouldn't help. And
> you can achieve the same effect for git-checkout itself with the option
> above.

Okay, it wouldn't help in that particular scenario (cherry-picking from a
remote), so I need to update the submodule manually in that scenario.

>  I'd like to reiterate that while this may seem convenient, I think it's
> dangerous to update the submodules silently. Maybe it's because I'm just
> too used to the default behaviour, but once you understand it, it's really
> not a problem to run "git submodule update" manually. Or at least a much
> lesser one than to have submodule change under you implicitly, IMO.

Let's consider some other scenarios:
 - using 'git bisect' to find a regression
 - using 'git switch --detach' to test behavior as of some prior SHA1
In such scenarios, it would seem that there's no easy general answer,
because rewinding a library submodule to a prior state (whether manually
or with a hook that does that automatically) is only a small part of the
work, while rebuilding it is a big task.

It depends on whether the library must be rebuilt. If I'm bisecting to
find a numerical lmi regression, then a hook that updates a wx submodule
is just a waste of time. If I'm trying to find a wx regression, then I
need to rebuild old wx versions, and I surely don't want a hook in the
lmi repository to do that.

More generally, I cannot 'git bisect' from the repository's first (2005)
commit to its last: I'd need to rebuild ancient versions of tools that
might not even be available today, or might require scripts or makefiles
that aren't even compatible with today's shell or 'make'.

I guess the conclusion is that using external libraries introduces
complexities; and bringing such libraries into git submodules does make
those complexities somewhat less difficult to manage, but does not
magically eliminate them. Well, a magical solution is possible--just
redesign the build system so that all libraries are dependencies--but
that's so much costly magic that we wouldn't want to do it.