On Fri, Jul 17, 2020 at 04:10:01PM +0200, Pavel Hrdina wrote:
On Fri, Jul 17, 2020 at 03:02:10PM +0100, Daniel P. Berrangé wrote:
On Thu, Jul 16, 2020 at 03:44:25PM +0200, Pavel Hrdina wrote:
On Thu, Jul 16, 2020 at 01:59:00PM +0100, Daniel P. Berrangé wrote:
Personally I'd really like to avoid squashing them, because splitting up big patches is not merely to benefit the initial pre-merge review, but to also benefit people who need to debug stuff that's already merged and understand the scope of the intended change. So being able to look back at the changes in isolation after commit is still a big plus point.
I would like to avoid squashing the patches as well and in most cases I would object to it as well. I only suggested that to not break git bisect.
If we don't care about git bisect and the fact that we would not be able to build libvirt correctly within these patches I'm OK with pushing it without squashing.
git bisect reliabity is key, so I reluctantly think we'll need to squash. I don't want to hit a pathc in this series with a bisect and be unable to continue the bisect due to inability to build the code.
I can try to rearrange the patches to not break git bisect. It will still require some script to be used for git bisect to detect if it should run autotools or Meson.
Maybe there's a reasonable tradeoff - instead of a 350 patch series, just a 10-20 patch series. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|