Re: [lmi] [PATCH] Use submodules for, and newer versions of, libxml2 and libxslt

[Vadim Zeitlin]

On Fri, 2 Oct 2020 13:41:22 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> Okay, let's try master, and adopt it unless we find a severe
GC> regression. If you would please update the github site, I'll
GC> test lmi with libxml2 master--I have the knowledge and hardware
GC> to do an acceptance test without much conscious thought, in the
GC> background, while I work on other things. And I create new
GC> chroots as freely as you create git branches, because those
GC> things cost nothing from our respective points of view.

 Thanks, I've created https://github.com/vadz/lmi/pull/154 now, which
contains a single commit c5f0f3600b2df631ea5199e46af90f0dd51c953e updating
just the submodule. I haven't yet had time to test it at all though, so
sorry in advance for any problems.

GC> BTW, what exactly does it mean to use libxml2 master? It
GC> must be the SHA1 that is HEAD at some moment,

 Yes, exactly, saying "libxml2 master" is just a language abuse and I
should have said "current libxml2 master <SHA-1>" or whatever.

GC> but when does that SHA1 change?

 When we decide it, i.e. not until we explicitly update our submodule to
another one. Just to forestall (or perhaps increase?) confusion, it _is_
possible to configure Git submodules to use the latest tip of some branch
rather than a fixed revision in the recent versions of Git, but this is not
how we're using them (and, IMHO, not how they should be used).

GC> Does it change whenever libxml2 is pulled to github?

 No (I assume you meant "pushed", but this doesn't change the answer).

GC> Would we be better off doing something more like
GC> what lmi's install_wx scripts do, i.e., fetch everything
GC> that's available, but then use a checkout as of some fixed
GC> SHA1 that's specified in the script?

 This is exactly how it works, except we don't need to do anything, Git
does it for us. From Git point of view, .gitmodules records the path to the
repository, while the actual commit (see e.g. PR 154 above) records the
SHA-1 of the revision of that repository which should be used. So it's
completely self-contained and stable, i.e. doesn't change unless we
explicitly commit the change to lmi.

GC> > GC> ...yes, please do update libxml2.
GC> > 
GC> >  I will do it soon but, just for the reference, the way it works is just
GC> > that you update the lmi branch in the submodule (in whichever way you see
GC> > fit, i.e. by fast-forwarding it to v2.9.10 tag, merging with master,
GC> > whatever), then pushing submodule to its origin (which, as I'm belatedly
GC> > realizing, you can't do without a GitHub account...)
GC> 
GC> Setting up a github account at this moment would just push
GC> one more task onto my stack, taking time away from other
GC> needful work that I already can't spend time on because
GC> that stack's too deep. You might say it's as simple as
GC> learning to work with git submodules, and even simpler than
GC> learning about git merges, but my stack has overflowed and
GC> push() throws an ENOTIME exception.

 I have originally misread this as "ENOTME" and was really afraid for a
moment about your psychological state but luckily it's not that. ENOTIME is
a perfectly fine chronic condition, which passes with time...

GC> One more question--is there a reasonable way to make the
GC> submodule directories reside somewhere else? I've found
GC> it convenient to run commands like
GC>   grep -r '/bin/sh' * |less

 You should use "git grep" instead. It doesn't require "-r", it skips all
untracked files (which you almost never want to search) automatically and
it has other nice features, like highlighting the matches, (optionally)
showing the function context and supporting Perl REs when you need them.

GC> which until now have conveniently looked in
GC>   lmi/src
GC>   lmi/src/gwc
GC>   lmi/src/tools
GC> but not in gobs of submodules. If they could live in
GC>   lmi/src/../third_party
GC> then I'd regain that convenience. But would that violate
GC> some precondition that git assumes?

 Yes, all repository contents must reside inside the repository. In fact
you _could_ trick Git by making third_party/foo symlinks to whenever you
want them to reside and then hiding the change from Git using update-index
--skip-worktree, and I do it to avoid having a zillion copies of wx
submodule on my system(s), but I strongly recommend _against_ doing this,
at least initially, because submodules can be tricky to get used to work
with without any dirty hacks on top of them.

 Please just use git-grep, with "alias g=git" it's just a single extra
letter which is compensated by not having to type "-r". And otherwise it's
exactly the same. Except better.

 Regards,
VZ

pgpLUciyBd4Bn.pgp
Description: PGP signature