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

Tue Jul 28 11:08:43 UTC 2020

On Tue, Jul 28, 2020 at 10:46:07AM +0100, Daniel P. Berrangé wrote:
>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.
>

Thank you for correcting me.  I genuinely believed that this was happening in
another project that I was bisecting, but I should've checked more.

I spent some more time looking at the workarounds and there are ways how to
achieve what I described.  Unfortunately it is not built in the bisect command
itself and there is nowhere to supply your own bisect helper or list of skipped
commits per-repo (which would be pretty easy and helpful, actually).  Anyway,
whatever does not work automatically with the unmodified `git bisect` command is
not going to be helpful, no matter how much we'd document it.

One other idea would be to have a Makefile (or some other mean) that just tells
you what to do if you got to any of the commits in the middle a bisect.  But
maybe I'm overthinking it.

Sorry, let's leave this, I guess.  I do not have any time to look at adding the
feature in git :)

>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 :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200728/4784791f/attachment-0001.sig>