On Tue, May 10, 2022 at 01:53:26PM +0200, Laszlo Ersek wrote: > On 05/10/22 13:10, Richard W.M. Jones wrote: > > On Tue, May 10, 2022 at 12:09:38PM +0200, Laszlo Ersek wrote: > > >> One thing to note is that libguestfs itself does not *consume* the > >> particular "common" contents that it generates. Therefore we don't have > >> a reference loop in practice. What we have is this dependency graph: > >> > >> libguestfs (generator) > >> | > >> v > >> libguestfs-common (generated content) > >> / \ > >> v v > >> guestfs-tools virt-v2v > >> > >> Because of that, the usual "update common submodule" hunk *need not* be > >> squashed into the libguestfs (generator) patches, when merging this. > >> However, said "update common submodule" hunk does have to be squashed > >> into the (single) guestfs-tools and virt-v2v patches, when merging. > > > > To be clear, while there isn't a separate "update common submodule" > > commit in libguestfs, the commit hash of libguestfs -> common > > submodule *will* still change (in the same commit that changes the > > generator)? > > I'll merge the libguestfs-common patch set, and the libguestfs patch > set, in unspecified order. > > Then there *will* be a separate commit in libguestfs that updates the > submodule reference. It's just that this change will be an entirely > stand-alone commit -- the submodule update hunk need not be squashed > into any of the other -- actual patch -- libguestfs commits.
Right, I totally missed that the hunk "*need not* be squashed". Anyway it's all good. > In other words, in the git history, there will be two stages where the > generator will output such content under "common" that actually differs > from the then-checked-out submodule content -- but that's fine, because > libguestfs itself does not "consume back" the same content. So this > (temporary) difference is harmless. > > For guestfs-tools and virt-v2v however, the difference is not tolerable. > Therefore, in each of those superprojects, I will extend the one patch > for that superproject, with the submodule update. So that the submodule > checkout and the dependent code advance in sync. > > > I looked at the patches through the mailing list archives and > > everything looks fine to me so you might as well push it all. If > > there are any problems I'm sure we'll find out soon enough. > > Thanks! > > > > > For the whole series: > > > > Acked-by: Richard W.M. Jones <[email protected]> > > > > (You don't need to add this because I guess it will mess up your > > carefully curated git commit hashes!) > > I will add it -- first because I have to extend the guestfs-tools and > virt-v2v patches for merging, like described above, anyway; second, I > need to be prepared for libguestfs-common moving forward mid-review in > any case. (I shouldn't expect actual conflicts, but the commit hash of > the HEAD could change.) > > I'll report back with the actual commit ranges. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html _______________________________________________ Libguestfs mailing list [email protected] https://listman.redhat.com/mailman/listinfo/libguestfs
