fix Issue 15019 - [ICE] Heisencrash on OS X 32-bit with non-trivial projects

[WalterBright]

https://issues.dlang.org/show_bug.cgi?id=15019

I don't know how this code ever worked.

[MartinNowak]

Should this go into 2.068.2? If so please reopen this against the stable branch.

[WalterBright]

Should this go into 2.068.2?

Yes. It fixes memory corruption, and so is a critical bug fix.

If so please reopen this against the stable branch.

1. I don't know how to do that. The last time I tried it horrible things happened.
2. I have no idea why cherry-pick would not work for this. I use cherry-pick all the time to merge fixes into other branches. Isn't this the whole point of cherry-pick?

[CyberShadow]

I don't know how to do that. The last time I tried it horrible things happened.

There is no button on GitHub to do it, a new PR has to be opened. You could e.g. close this PR, run git rebase "fix15019^" fix15019 --onto origin/stable, then force-push fix15019 and open a new PR against stable (choose the target branch in GitHub's PR form).

I have no idea why cherry-pick would not work for this. I use cherry-pick all the time to merge fixes into other branches. Isn't this the whole point of cherry-pick?

The problem with cherry-pick is that it doesn't merge changes, it copies them, which causes two copies of the same change to exist in the repository and its history. This confuses git when later merging things, causes problems for tools like Digger, and is generally confusing ("Which commit introduced that change? This one? Then what's this other commit with the exact same diff?")

[WalterBright]

This confuses git when later merging things,

Why would stable ever get merged into head? Things should be going the other way.

causes problems for tools like Digger, and is generally confusing ("Which commit introduced that change? This one? Then what's this other commit with the exact same diff?")

If changes are first introduced into head, then cherry-picked as required into other branches, I don't see the problem.

And lastly, changes put into stable would then have to be cherry-picked into head. Wouldn't that be the exact same issue?

[dnadlinger]

And lastly, changes put into stable would then have to be cherry-picked into head.

No, the stable branch can be merged into master instead of duplicating a subset of the commits (i.e. cherry-picking the other way).

[WalterBright]

No, the stable branch can be merged into master instead of duplicating a subset of the commits (i.e. cherry-picking the other way).

The assumption that all commits to stable should be merged into head is unfounded.

[MartinNowak]

The assumption that all commits to stable should be merged into head is unfounded.

We decided for this b/c it's the cleanest workflow, makes it easy to find out which release contains a particular fix, and avoids plenty of merge conflicts.
And yes any fix on stable should end in master, though they might need to be adjusted when merging them back.
We do this for some time now and it made maintaining the stable branch a lot easier, let alone that the cdmd to ddmd merges wouldn't be possible as cherry-picks.

Meanwhile we missed to fix this issue, please make a Trello card or at least add a milestone to the PR so I have a chance to keep track of what needs to be done.