lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg Chicares
Subject: Re: [lmi] Should we update libxml and its kin?
Date: Fri, 18 Mar 2022 20:36:50 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0

On 2022-03-18 18:34, Vadim Zeitlin wrote:
> On Fri, 18 Mar 2022 15:34:27 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> created https://gitlab.gnome.org/GNOME/libxml2/-/merge_requests/151 and we
> could just update to the latest libxml2 master if it's merged soon.
> 
> GC> If you agree, and I make that change and push it, will the rest of
                                ^^^^^^^^^^ same as your "151" above, but local
> GC> the lmi world update cleanly on the next git-pull 
> 
>  Otherwise, or if you just don't want to wait, you could, of course,
> already do this right away.

I really want to get this all resolved now so that I can update all our
chroots everywhere and get a clean 'git status'.

> GC> or could this have some disastrous effect that I don't know about, e.g.
> GC> because I'd be grafting something new (and unknown to upstream libxml2)
> GC> onto a detached HEAD?
> 
>  No, there is already a "lmi" branch in our clone of the upstream
> repository. Right now it's practically a clone of master (a couple of
> commits behind it, corresponding to the changes in the upstream since my
> last update), i.e. doesn't contain any commits not in master. But we can
> perfectly well have our own commits in this branch, this is what is for.
> The only minor drawback is that we would have to merge, and not just
> fast-forward, the upstream master the next time we update our library once
> we have any such commits. But, again, this is not really a problem and is
> just the way things are supposed to work.

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

--8<----8<----8<----8<----8<----8<--
commit ece006579f88cca67e9340e6676fd4e32296ee35 (HEAD)
Author: Gregory W. Chicares <gchicares@sbcglobal.net>
Date:   2022-03-18T19:19:35+00:00

    Ignore stray 'configure~'
    
    This is the same as:
    
    https://gitlab.gnome.org/_VZ_/libxml2/-/commit/\
    6025ecce5182d7c464e4b881d496824354a40f12
    
    See the thread culminating here:
      https://lists.nongnu.org/archive/html/lmi/2022-03/msg00029.html

diff --git a/.gitignore b/.gitignore
index ad751e89..85897bc9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -24,6 +24,7 @@ config.log
 config.status
 config.sub
 configure
+configure~
 dba100000.xml
 depcomp
 doc/Makefile
--8<----8<----8<----8<----8<----8<--

...locally:

/opt/lmi/src/lmi[0]$git -C third_party/libxml2 commit --all
[detached HEAD ece00657] Ignore stray 'configure~'
 1 file changed, 1 insertion(+)

but git-status wasn't yet clean:

  /opt/lmi/src/lmi[0]$git status
  On branch master
  Your branch is up to date with 'origin/master'.

  Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git restore <file>..." to discard changes in working directory)
          modified:   third_party/libxml2 (new commits)

  no changes added to commit (use "git add" and/or "git commit -a")

and then when I tried each of the following commands:

  git push
  git push --recurse-submodules=check
  git push --recurse-submodules=on-demand

all I ever got was "Everything up-to-date".

This (in the submodule's directory) seemed promising:

/opt/lmi/src/lmi/third_party/libxml2[0]$git push
fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use

    git push origin HEAD:<name-of-remote-branch>

However:

/opt/lmi/src/lmi/third_party/libxml2[0]$git push origin HEAD
Username for 'https://github.com': ^C

Really, github is origin, not savannah?

/opt/lmi/src/lmi/third_party/libxml2[130]$git remote -v
origin  https://github.com/let-me-illustrate/libxml2.git (fetch)
origin  https://github.com/let-me-illustrate/libxml2.git (push)

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

If my reasoning is correct, then could I ask you to make
the appropriate changes to all five of lmi's submodules
on savannah yourself, or tell me how to do it? I figure
it might be something like:
  git remote set-url origin git://git.savannah.nongnu.org/lmi.git
(followed by some kind of push command), and then on my
own personal development machines:
  git remote set-url --push origin SECRET_NAME@git.sv.gnu.org:/srv/git/lmi.git
but such tools in my hands are like what 'Papa' Monzano
kept in that cylinder on his neck-chain, and I might
potentially ah-whoom all of github.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]