On 05/10/22 14:21, Richard W.M. Jones wrote: > 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.
libguestfs commit range 00b9ef239342..08c4ac90f5a3 libguestfs-common commit range 81f86a0058a9..48527b8768d7 guestfs-tools commit 19de3d1c8d4e virt-v2v commit 0c24fc6015ce Thanks! Laszlo _______________________________________________ Libguestfs mailing list [email protected] https://listman.redhat.com/mailman/listinfo/libguestfs
