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

[Vadim Zeitlin]

On Fri, 18 Mar 2022 15:34:27 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2022-03-18 15:15, Vadim Zeitlin wrote:
GC> [...]
GC> >  You'd need to check what exactly is the "untracked content". It might be
GC> > just some stupid debug file (e.g. "configure~"), in which case it can be
GC>                                      ^^^^^^^^^^ yes, exactly
GC> > (a) ignored or (b) suppressed locally by adding this file to
GC> > third_party/libxml2/.git/info/exclude or (c) suppressed globally by adding
GC> > it to third_party/libxml2/.gitignore updating the submodule. I didn't do
GC> > (c) because I planned to patch automake to add an option to avoid creating
GC> > these files in the first place as discussed in
GC> > 
GC> >   https://savannah.gnu.org/support/?110417
GC> > 
GC> > but I didn't have time to do it yet. Maybe I should,
GC> 
GC> That would be good for the long run.

 OK, I won't move it to "TODO soon" column of my TODO list then...

GC> > or maybe (b) could be a good enough workaround for now.
GC> 
GC> Why (b) instead of (c)?

 Because it's just simpler/faster. With (c) you need to make a commit to
the submodule, push it, make a commit to the parent repository and push it
too. With (b) you just edit a file and that's all.

GC> The file in (b) doesn't exist now, and neither does its directory.

 Sorry, that's because it's a submodule. The correct file path is
.git/modules/third_party/libxml2/info/exclude

GC> The file in (c) already exists, and contains 127 names of files like
GC>   config.h.in~
GC> that should be ignored. Now we have a new file 'configure~' that
GC> should likewise be ignored. Wouldn't adding 'configure~' to this
GC> existing .gitignore file be the most concinnous change?

 Yes, it would. I was just too lazy, so to compensate for it, I've now
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
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.

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.

 Regards,
VZ

pgpgNBk6GpWCP.pgp
Description: PGP signature