[umbrello] [Bug 445119] Issues with code ignoring and possibly dereferencing nullptr

[Robert Hairgrove]

[Replying only to Umbrello development list here:]

On 2021-11-23 05:31, Ralf Habacker wrote:
> https://bugs.kde.org/show_bug.cgi?id=445119
> 
> --- Comment #4 from Ralf Habacker <ralf.habacker at freenet.de> ---
> (In reply to Robert Hairgrove from comment #3)
>> What I can envision now, without knowing all of the details about how 
>> this
>> class is used, is the following:
>> 
>> 1. Class UMLObjectList should inherit from QObject, or possibly just
>> implement signals and slots using the Q_OBJECT macro;
>> 2. UMLObjectList should connect itself via slot to the "destroyed()" 
>> signal
>> of each element added to its list which should only be permitted 
>> through its
>> own "append()" function (and removal through a correlated "remove()"
>> function);
>> 3. Whenever a contained element is destroyed, the slot would have to 
>> find
>> the pointer in its list and then remove it. Of course, the actual 
>> object
>> deletion would be left to QPointer.
> 
> Feel free to open working branches in your private umbrello git repo on
> invent.kde.org where you can add and test appropriate things and result 
> in a
> merge request. If such a merge request is not yet ready, a draft can be 
> marked
> with the WIP: prefix.
> 
> The easiest merge requests to test are those that consist of smaller,
> self-contained changes.

Thanks, Ralf.

In the past, I have had trouble with rebasing when requesting merges (I 
contributed one commit for wrapping text in use cases, but it failed 
constantly until you saved it).

Since I cannot find any guidelines about this anywhere (maybe they were 
there in the past?), what is the branch I need to base my merge request 
on after forking the project?

There are many Git experts out there (I am certainly not one of them) 
who believe that "rebase", "cherrypick", etc. are of the "Evil Empire", 
as far as Git goes. :) But I tend to agree with this view from past 
experience.