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 <rjones(a)redhat.com>
>>
>> (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