Re: [lmi] Tests PR 174

[Vadim Zeitlin]

On Wed, 24 Mar 2021 21:56:56 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 3/24/21 7:43 PM, Greg Chicares wrote:
GC> [...]
GC> > Please take a look at commit 593a7121f737, which may be
GC> > erroneous. 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. Now it looks
GC> > like I should have ignored it...and instead have used
GC> > "git restore" to discard it? Is that the proper way to
GC> > get git-status to report that everything's clean?
GC> 
GC> Well...I rebuilt, in an experimental chroot, with lmi HEAD
GC> as it now stands, and it produced a wx dll with suffix
GC> "-6cdaedd4.dll", which is the old SHA1, so my "git add"
GC> was definitely wrong, and I have to revert it.

 It looks like you had written this before getting my previous reply, but
you should have received it by now, so I won't repeat it here other than to
confirm that yes, reverting it, as you just did, was the right thing to do,
thanks!

GC> But how can we prevent this in the future?

 FWIW I don't think you should prevent it from happening. Updating local
submodules should be a conscious decision and there is nothing particularly
bad if it doesn't get updated automatically, you can see that it is
modified and update it manually. This should happen pretty rarely, after
all.

GC> Should we set
GC>   git config --global submodule.recurse true

 I don't use this option myself, but it looks like it should do what you
want, yes. However I am not sure if it applies to git-cherry-pick as the
documentation says that it affects all commands with --recurse-submodules
option, but this one doesn't have such an option, unlike git-fetch,
git-pull or git-checkout. And, indeed, after checking it quickly, the
option doesn't affect its behaviour with my Git 2.31.

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.

 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.

 Regards,
VZ

pgpa2NBRcSyxb.pgp
Description: PGP signature