Ping! This should be low hanging fruit

This pull request is ready to merge

Merged.

a076951 X509_PUBKEY_set(): Fix memory leak

Thanks @DDvO, for showing by example how to get these merges properly visible on github

Thanks @DDvO, for showing by example how to get these merges properly visible on github

Oh, why do you think I've done that? At least I did not do consciously.
Maybe my wife did that, but in this case the button would have been pink instead 😉
I suppose it's just a new GitHub feature that I happened to trigger first?

Oh, why do you think I've done that? At least I did not do consciously.
Maybe my wife did that, but in this case the button would have been pink instead wink
I suppose it's just a new GitHub feature that I happened to trigger first?

Normally when we push a github PR, we have to rebase it first. Therefore github does not recognise that we've actually pushed it, and always thinks that we've closed the PR unmerged. By force-pushing the PR to github first (as you did in #10667) and then pushing to master, github is recognising that the PR has been merged, closes it automatically and shows the "Merged" icon.

More so, addrev rewrites history, meaning that the commits that end up in master diverge from the PR branch, but force-pushing after addrev makes it look nicer.

May I ask @DDvO to incorporate the brilliant changes he made to the workflow @mspncp has provided?

Thanks @mattcaswell, @levitte, and @beldmit for your affirming and well explaining further comments that you gave 4 days ago, which I did not notice until now.

May I ask @DDvO to incorporate the brilliant changes he made to the workflow @mspncp has provided?

@beldmit did you mean by 'incorporate' to reflect the workflow enhancements in ghmerge, i.e., as a further tweak in openssl/tools#59 ?
If so, I don't think this is possible in general because it requires modifying the commits in the contributor's repo.

@beldmit did you mean by 'incorporate' to reflect the workflow enhancements in ghmerge, i.e., as a further tweak in openssl/tools#59 ?
If so, I don't think this is possible in general because it requires modifying the commits in the contributor's repo.

I'm just interested in a list of github commands.
Now I use these options:

git fetch --all && git checkout master && git pull
git branch -D pr-xxxx
git checkout pr-xxxx
git rebase -i master
addrev --prnum=xxxx @mattcaswell @beldmit master..HEAD
git push origin HEAD:master

And have to close the PR manually. Your workflow, as I understand, is better.

@beldmit, your workflow would get adapted to something like the following
in order to lead GitHub to recognize that the branch has been merged.
Note that the push to pr-xxxx.orig is optional for keeping a copy of the branch before it is squashed, which has been discussed with @bernd-edlinger - see #10620 (comment).

git fetch --all && git checkout master && git pull
git branch -D pr-xxxx
git checkout pr-xxxx
git checkout -b pr-xxxx.orig && git push -u <remote>  pr-xxxx.orig && git checkout pr-xxxx     # do a backup
git rebase -i [--autosquash] master                     # rebase and do all squashing you want to do
addrev --prnum=xxxx @mattcaswell @beldmit master..HEAD
git push -f                                             # update the online branch of the PR
git push origin HEAD:master

BTW, I recently again came across the topic of marking successful merge of a PR by the purple "Merged" GitHub symbol.

I've tried out on #12615 an enhancement of the procedure mentioned above, using the latest version of ghmerge.
In the shell that I used for editing that PR I called

git fetch upstream; git rebase -i --autosquash upstream/master
addrev [email protected] 12615 mattcaswell

which already added to the respective commit message(s):

    Reviewed-by: Matt Caswell <[email protected]>
    (Merged from https://github.com/openssl/openssl/pull/12615)

Then I force-pushed to the PR (which some committers consider unclean because strictly speaking this overwrites the approved version, but just by a likely rebase, possibly squashing, and meta info addition):

git push --force-with-lease

Then (in a different shell where I do the merge commands) I entered as usual:

ghmerge --nobuild [email protected] 12615 mattcaswell

which did not further modify the commits because its internal addrev call realized that the meta info was already present.
So this rather simple merge procedure had the desired effect of producing the purple icon 🚀