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 :|
