Re: [lmi] Should we update libxml and its kin?

[Vadim Zeitlin]

On Fri, 18 Mar 2022 20:36:50 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> Then this sounds like the right thing to do. But it seems that I cannot
GC> do it myself. I committed this...

 The first (yes, sorry, there are going to be a couple) problem is that
you've made this commit not on lmi branch, but in the "detached HEAD"
state. So it's not part of the lmi branch and can't be (easily) pushed to
its remote counterpart.

 One of the surprising things with submodules is that are in the "detached
HEAD" state by default, so you need to explicitly "git switch lmi" (or
whichever branch you're using) before making any changes to them. It's best
to do it before making changes but you can, of course (we're speaking of
Git, after all, where anything is possible), recover now too, please see
below.

GC> --8<----8<----8<----8<----8<----8<--
GC> commit ece006579f88cca67e9340e6676fd4e32296ee35 (HEAD)
...
GC> --8<----8<----8<----8<----8<----8<--
GC> 
GC> ...locally:
GC> 
GC> /opt/lmi/src/lmi[0]$git -C third_party/libxml2 commit --all
GC> [detached HEAD ece00657] Ignore stray 'configure~'
GC>  1 file changed, 1 insertion(+)
GC> 
GC> but git-status wasn't yet clean:
GC> 
GC>   /opt/lmi/src/lmi[0]$git status
GC>   On branch master
GC>   Your branch is up to date with 'origin/master'.
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/libxml2 (new commits)
GC> 
GC>   no changes added to commit (use "git add" and/or "git commit -a")

 But let me also speak of the second problem, as it's even simpler: here
you didn't commit the changes to the submodule, so you can't push them. A
submodule is a repository and not a plain file, but it still follows the
same rules as the files, i.e. you need to "git add" it before committing
(or you can just "git commit third_party/libxml2" directly, which combines
both steps, but conceptually it still works the same as with plain files).

GC> and then when I tried each of the following commands:
GC> 
GC>   git push
GC>   git push --recurse-submodules=check
GC>   git push --recurse-submodules=on-demand
GC> 
GC> all I ever got was "Everything up-to-date".

 Right, you don't have any commits locally that don't exist remotely. Or at
least you don't have them yet -- once you commit the submodule, you will.

 This is the second surprising thing about Git submodules: each change in
them needs at least 2 commits, one (or more) in the submodule itself and
then another commit in the parent repository. Granted, this is surprising
if you think of submodules as something special but not so surprising if
you just think of the usual Git rules: after changing something, you still
need to commit the changes. So far you've only changed the submodule in the
working copy, as you can see with e.g. "git diff", but not in the
repository.

GC> This (in the submodule's directory) seemed promising:
GC> 
GC> /opt/lmi/src/lmi/third_party/libxml2[0]$git push
GC> fatal: You are not currently on a branch.
GC> To push the history leading to the current (detached HEAD)
GC> state now, use
GC> 
GC>     git push origin HEAD:<name-of-remote-branch>

 You could do this, but it would be better to switch to lmi branch locally
first as then you should be able to do just "git push". So let's solve the
first problem now: in the submodule directory, please run

        $ git branch my # just a temporary name, not to deal with SHA-1s
        $ git switch lmi
        $ git merge --ff-only my # it should be a fast-forward
        $ git branch -d my # not needed any longer, so clean it up

 Now you should be able to do "git push" and, actually, should do it, to
ensure that the remote repository contains your changes before pushing the
parent repository (you can commit the parent repository before if you want,
but pushing it before pushing this one would be a problem and would fail
with --recurse-submodules=check option).

GC> However:
GC> 
GC> /opt/lmi/src/lmi/third_party/libxml2[0]$git push origin HEAD
GC> Username for 'https://github.com': ^C
GC> 
GC> Really, github is origin, not savannah?

 This is the third problem: yes, all the submodules currently exist on
GitHub only. I think we discussed this when adding them and I had some
argument about this not really being a problem because their upstream
versions were all already on GitHub anyhow, but if you'd like to change
this, we should be able to. However it's probably best to leave this for
later, after the first two problems are fixed.

GC> Confirmed. AIUI, savannah should already host a complete
GC> bare repository of each submodule, so shouldn't each
GC> submodule's origin be savannah?

 I don't think Savannah has them. We should be able to create them, of
course, but it's going to be problematic to configure the repository to
check the submodules out of the same hosting site from which the main
repository itself was cloned. Usually to allow this relative URLs are used
in .gitmodules, but in this case I don't think it's going to be possible,
GitHub insists on using org/repo format, while Savannah doesn't allow this,
AFAIK. I.e. we'd have to use lmi-libxml2, lmi-wx, etc for the repositories
names there.

GC> If my reasoning is correct, then could I ask you to make
GC> the appropriate changes to all five of lmi's submodules
GC> on savannah yourself, or tell me how to do it?

 I think it would be best for you to create them, so that they belong to
the same account as the main lmi repository.

GC> I figure it might be something like:
GC>   git remote set-url origin git://git.savannah.nongnu.org/lmi.git
GC> (followed by some kind of push command),

 No, this wouldn't need to be pushed anywhere, your remotes are configured
locally. It's just that they're initialized from the URLs in .gitmodules by
default, so you would have to edit this file and commit/push it as usual.

 I don't know if I should also set up mirroring between Savannah
repositories for the submodules and those on GitHub in the same way as I do
for the main repository? Submodules change much less often, so maybe it
would be enough to push to both destinations on the rare occasions when
they do change? In any case, I assume you still want to have the mirrors on
GitHub.

 But, again, the main problem I see is that now submodules will be cloned
from Savannah even if the main repository is cloned from GitHub. So things
won't work any more for somebody cloning lmi from GitHub because access to
Savannah is blocked. So maybe the best thing to do would be to leave the
"primary" submodule repository on GitHub and just mirror them on Savannah
instead?

GC> but such tools in my hands are like what 'Papa' Monzano
GC> kept in that cylinder on his neck-chain, and I might
GC> potentially ah-whoom all of github.

 If you manage to do this, you would have to accept a huge bounty payment
from Microsoft, so you probably don't want to start.

 Regards,
VZ

pgpBH8RbdgVP2.pgp
Description: PGP signature