[libvirt PATCH 000/351] port libvirt to Meson build system

[Daniel P. Berrangé]

On Fri, Jul 17, 2020 at 07:27:50PM +0200, Martin Kletzander wrote:
> 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.

I'm not sure I follow exactly what you are saying here, so let me try to
illustrate what I think you mean and you can correct me.

Consider that

  - The current repo has commits A, B and C
  - The Meson series has commits R, S, T and U
  - After meson, we add commits H, I and J

IIUC, by "semi-linear merge" you mean a graph that looks
like this:

  A----B----C---------------------------H----I----J
            |                           |
            +-----R-----S----T-----U----+


Now we notice a regression at J and know the last good commit was B.

IIUC you're saying that when "git bisect" runs it will stop on
commits 'C' and 'H', and only bisect into R, S, T, & U, if
the results of C & H show the problem is in the meson series.

That would certainly be nice, but I can't find any documentation
that clearly says this is what git bisect will do.

The docs I see merely say that bisect will look for a commit half way
between the current good & bad markers, but doesn't clarify what
"half way" means when there are two possible paths to follow in
the graph. You seem to be saying it will choose the shorter of the
two paths, but I don't see that mentioned anywhere. I could easily
see it deciding the "S" was the first half-way points to try, not
C or H.

If someone can point me to credible docs explaining what git does
wrt merges I'd be interested if I'm right or wrong.

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