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

[Vadim Zeitlin]

On Wed, 30 Sep 2020 13:28:23 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2020-09-29 23:57, Vadim Zeitlin wrote:
GC> >  Here is, finally, the promised patch:
GC> > 
GC> >   https://github.com/vadz/lmi/pull/153
GC> 
GC> Two questions:
GC> 
GC> (1) Is this a correct way of incorporating that PR into lmi?
GC>   [where "xanadu" is your github repository]
GC>   git fetch xanadu
GC>   git merge xanadu/submodule-for-xml-libs

 Yes, absolutely. However we've found a mistake in the first commit. For
now I've pushed it to the same PR (so now it should have 3 commits instead
of 2), but if you don't mind, I'd like to rebase it to merge it into the
first commit. Please let me know if I can do this -- this would rewrite the
existing commits, so you would need to redo "git fetch xanadu" again, but
if you haven't merged this branch yet, this shouldn't be a problem. If you
did already merge it, it's probably not worth the trouble and I'll have to
consign the record of my inattentiveness to the annals of history.

GC> (2) As a consequence of git-links used for submodules, is it
GC> expected that these:
GC>   drwxrwxr-x 2 greg greg 4096 Sep 30 12:01 third_party/libxml2
GC>   drwxrwxr-x 2 greg greg 4096 Sep 30 12:01 third_party/libxslt
GC> have been added, apparently as normal subdirectories with no
GC> {suid, sgid, sticky} bits set?

 Yes. Git submodules are just empty directories as long as they're not
initialized. Once you initialize them using "git submodule init" or, more
commonly, "git submodule update --init" (because initializing a submodule
without updating it is rarely useful), they will be filled with the child
repository contents and a special ".git" file pointing to the parent module
".git" directory (but it's an internal implementation detail and you
shouldn't care about it).

GC> Full details below in the stream of consciousness that led to
GC> those questions, but feel free to skip it...
GC> 
GC> Instead of cherry-picking both commits, I tried this:
GC> 
GC> /opt/lmi/src/lmi[0]$git fetch xanadu 
GC> remote: Enumerating objects: 3, done.
GC> remote: Counting objects: 100% (3/3), done.
GC> remote: Total 9 (delta 3), reused 3 (delta 3), pack-reused 6
GC> Unpacking objects: 100% (9/9), done.
GC> From https://github.com/vadz/lmi
GC>    3299d705..f94663e9  master                 -> xanadu/master
GC>  * [new branch]        submodule-for-xml-libs -> 
xanadu/submodule-for-xml-libs
GC> /opt/lmi/src/lmi[0]$git merge xanadu/submodule-for-xml-libs      

 I'm not sure which branch did you try this on. If it was master, then I
won't rebase the existing commits in the PR and you just need to apply the
latest one on top of the ones you already have -- you can just merge again
(after fetching again) with "--ff-only" option because this will still be a
fast-forward.

 If it was some temporary branch, I'd prefer if you deleted it, then I
rebased the commits in the PR and then you merged them again into master.

GC> Everything seems to have worked except that there's nothing in the
GC> third_party/ subdirectories:

 Yes, this is perfectly normal, you do need to initialize (and update)
them.

GC> so "mode 160000" must be git's internal modes:

 Yes, absolutely, it is not the same as Unix file mode (although obviously
inspired by it).

 Please let me know if I can -- or can't -- rebase the PR, thanks in
advance,
VZ

pgpUIytppYkPw.pgp
Description: PGP signature