Re: wip/soundfont (and wip/ branches)

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Tue, Sep 20, 2016 at 07:09:52PM +0200, Tim Janik wrote:
> On 20.09.2016 15:48, Stefan Westerfeld wrote:
> > I squashed the whole SoundFont stuff into one commit, making it easier to merge
> > for me. It contains
> >
> >  - my original submission
> >  - everything from your wip/soundfont
> >
> > and was rebased to the BEAST master branch, and fixed to the degree to make it compile.
>
> Hi.
> I don't like the idea of squashing the branch for the following reasons:
> - Squashing looses attribution of the individual changes.
> - Branch history is lost, i.e. which linediff can be attributed to which commit (and its stated intent).
> - Also, the signoff is now missing from all commits/changes.
>
> So please add your signoff [1] to changes you make (e.g. use git commit -s), and merges you are editing.
Ok.

> Loosing that information can impose a significant drawback if any of the changes has to be debugged.

Right. So if preserving commits/author/signoff is important, we can either
rebase or merge. I didn't want to rebase because the problem is that if you
have 10 commits, and are rebasing commit 3, it can be that you fix something
that already has been fixed in some later commit. Therefore squashing appeared
to be the better option.

But ok, merging as described below would also solve my issue, because then the
branch would still be treated as a whole entity (doing rebase follows the
history of the branch step by step which can cause problems).


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

> Since you used git to merge and resolve conflicts, the repository you did the conflict resolutions in
> should have kept the preimages and resolutions for all your conflicts in the rerere cache. [2]
> So using that same repository, you should now be able to rebase wip/soundfont onto master, preserving
> the individual commits, with git automatically applying the resolutions you previously used from its
> rerere cache. That should make rebasing without squashing a lot easier.
>
> Or alternatively, keep the branching point of wip/soundfont the same and just merge master into the
> branch tip (might make resolution easier for git). - Thinking of it, this approach is probably even
> better here, as rebasing requires editing someone else's commits, while merging clearly attributes
> the conflict resolution edits and is non-destructive. [3]

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.

   Cu... Stefan
-- 
Stefan Westerfeld, http://space.twc.de/~stefan