Re: wip/soundfont (and wip/ branches)

[Tim Janik <timj gnu org>]

On 21.09.2016 12:49, Stefan Westerfeld wrote:
> > > However if you start BEAST, go to SoundFont repository and click load
> > > and load a sound font, this is what happens:
> > >
> > >   beast-0.10.1: bseobject.cc:167: void bse_object_init(BseObject*): Assertion `in_bse_object_new' failed.
> > >   Abgebrochen (Speicherabzug geschrieben)
> > >
> > > This sounds like something that should be very easy to fix for you, since you
> > > know what changes to the object system you did that caused this problem.
> >
> > And there we go, seems debugging is the next step neccessary...
>
> Ok. I know that it didn't fail back then when I wrote the code, so I had hoped
> that this was caused by infrastructure changes, and you'd recognize the error
> message and know what to do. Well, I'll try to figure out myself what needs to
> be changed.

If you want me to guess, it could be related to bse_object_new now hardcoding the C++ object types that are 
paired with a GType object.
But you're right it needs further investigation.

> Are you sure? If I merge master into the wip/soundfont branch, as in
>
>   (on wip/soundfont)$ git merge master
>
> then this will generate a commit with houndreds of changes that are completely
> unrelated to the soundfont branch (because it will merge every single thing
> that has changed in master since then), and among these changes a few that are
> related.
>
> I can do this, but it doesn't make the actual merge changes as obvious as for
> instance my squash commit or rebasing.
>
> It would work the other way round, by starting from a new branch from master:
>
>   (on master)$ yybranch wip/soundfont-merge
>   (on master)$ yywarp wip/soundfont-merge
>   (on wip/soundfont-merge)$ git merge wip/soundfont
>
> which is basically the same as just merging the branch into master, except that
> it is done in an extra branch, and it would
>
>  - show the changes clearly (unlike merging master into wip/soundfont)
>  - not edit or squash old commits (lossless)
>  - the resulting branch can be pushed to origin and should merge cleanly
>  - however it would not have linear history any longer
>
> It sounds like a plausible way to go.

If I'm not mistaken, both ways will create the exact same kind of merge commit, the only thing different is 
just that the resulting branch you end up with is either named wip/soundfont-merge or wip/soundfont.

But maybe I'm missing something...

>    Cu... Stefan

-- 
Yours sincerely,
Tim Janik

https://testbit.eu/timj/
Free software author.