On Fri, Jul 17, 2020 at 03:12:00PM +0100, Daniel P. Berrangé wrote:
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.
One other option would be a semi-linear merge. bisect would try the commit
before the rewrite and after, if both of them worked or both were broken then it
will not try the commits in the middle. If it does, then you know it was
because of the autotools=>meson rewrite. You will not break git-bisect and
you'll keep the history of the commits.