[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.
- Re: [lmi] Should we update libxml and its kin?, Vadim Zeitlin, 2022/03/10
- Re: [lmi] Should we update libxml and its kin?, Greg Chicares, 2022/03/17
- Re: [lmi] Should we update libxml and its kin?, Vadim Zeitlin, 2022/03/17
- Re: [lmi] Should we update libxml and its kin?, Greg Chicares, 2022/03/17
- Re: [lmi] Should we update libxml and its kin?, Vadim Zeitlin, 2022/03/18
- Re: [lmi] Should we update libxml and its kin?, Greg Chicares, 2022/03/18
- Re: [lmi] Should we update libxml and its kin?, Vadim Zeitlin, 2022/03/18
- Re: [lmi] Should we update libxml and its kin?, Greg Chicares, 2022/03/18
- Re: [lmi] Should we update libxml and its kin?, Vadim Zeitlin, 2022/03/18
- Re: [lmi] Should we update libxml and its kin?,
Greg Chicares <=
- Re: [lmi] Should we update libxml and its kin?, Vadim Zeitlin, 2022/03/18
- Re: [lmi] Should we update libxml and its kin?, Greg Chicares, 2022/03/20
- Re: [lmi] Should we update libxml and its kin?, Vadim Zeitlin, 2022/03/21
- Re: [lmi] Should we update libxml and its kin?, Greg Chicares, 2022/03/21
- Re: [lmi] Should we update libxml and its kin?, Vadim Zeitlin, 2022/03/21
- Re: [lmi] Should we update libxml and its kin?, Greg Chicares, 2022/03/21
- Re: [lmi] Should we update libxml and its kin?, Greg Chicares, 2022/03/18