Re: wip/soundfont (and wip/ branches)

[Tim Janik <timj gnu org>]

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.

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

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

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]

>    Cu... Stefan

[1] Signed-off-by certifies agreement to the Developer Certificate of Origin: http://developercertificate.org/
[2] See also GIT-RERERE(1).
[3] https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview

-- 
Yours sincerely,
Tim Janik

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