On Mon, May 22, 2023 at 02:46:34PM +0200, Laszlo Ersek wrote:
On 5/19/23 18:31, Richard W.M. Jones wrote:
>
> For the series:
>
> Reviewed-by: Richard W.M. Jones <rjones(a)redhat.com>
Thanks!
Commit range 67647b883e13..569bd1dd29da.
>
> BTW it's usually possible to cherry pick across git repos, eg:
>
> $ git fetch ../libguestfs
> $ git cherry-pick -x <hash>
Hm, good to know, thanks! I didn't know you could use git fetch this
directly. Minimally I would have expected having to add a file:// scheme
remote, before the fetch. In retrospect, the third paragraph of the
git-fetch manual mentions "URL", and then the "GIT URLS" section
mentions the example "/path/to/repo.git/". Too much documentation to
read! :)
Regarding the cherry-pick -- I wonder how helpful it could have been.
Sometimes it is surprisingly clever, in resolving conflicts. This time I
copied "make-fedora-img.pl" from the already modified project(s) to the
next project, and used "git add -p" to review and stage the changes I
wanted. And then I compared the candidate patch to the actual commit in
the other (already modified) project(s), effectively looking at
"interdiff"s. There was at least one surprise that way: see virt-v2v
commit fd7cd0c0fd22 / guestfs-tools commit 21e051c0c846. We don't have
the same in libguestfs (in fact I'd not been aware of guestfs-tools
commit 21e051c0c846!), and now I didn't want to change the size of the
Root LV -- there seemed to be no justification for that.
Yes it definitely depends on the number of separate changes that have
been made, and also whether previous changes were cherry picked in the
same order (or at all). You can get two files that should supposedly
be the same getting so out of synch that simply copying the files and
reviewing the changes is better.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit