I'm not sure about the process here, but shouldn't the new commits on release-19.09 be cherry-picked from master instead of having a custom-made commit?

It seems that it should be backported from other PR which I did. I can be wrong tho! @rht

@JeffLabonte See https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md#backporting-changes.

Comment from IRC was:

the commit header in the backport PR is different from the commit on master
(the backport PR) nixos: Update brave from 1.3.118 to 1.4.95 (on master) brave: 1.3.118 -> 1.4.95
the latter commit message is correct per the contribution guidelines (pkgname: old_verison -> new_version)

The above can be done by just doing git cherry-pick -x (e also if you want to edit the message with a reason).

Is this really a pure cherry-pick?
There is a sub-commit message
Update brave from 0.69.128 to 1.4.95

which means the commit that updates 0.69.128 to 1.3.118 was squashed into the commit that updates 1.3.118 to 1.4.95

Is this really a pure cherry-pick?
There is a sub-commit message
Update brave from 0.69.128 to 1.4.95

which means the commit that updates 0.69.128 to 1.3.118 was squashed into the commit that updates 1.3.118 to 1.4.95

Oh you're right. I guess it's too late now :rofl Extra cherry-picked commits in that case (it would have been two) would have been fine.

@worldofpeace will the mistake be resolved manually during the merge conflict resolution with unstable? How is this usually resolved?

Commit messages can't be changed now; we don't do any history rewriting on these branches (and this isn't really a strong reason). Conflicts in git are only concerned with file contents and not commit messages, and we don't merge between master/unstable and stable branches... perhaps I misunderstood the question.

@vcunat

Conflicts in git are only concerned with file contents and not commit messages

I am concerned with the jump in the diff since 0.69.128 to 1.4.95 instead of 1.3.118. There will be a conflict during the cherry pick.

we don't merge between master/unstable and stable branches...

OK, I think I don't know the mechanism behind how the stable branches are being updated so as to not fall behind master/unstable. I assume it is a merge operation between a sufficiently mature version of old master/unstable, not a continuous cherry-pick from master/unstable.

If the following cherry-picks use commit starting with 1.4.95, it should be conflict-less. In any case, these bumps seem to need no other changes, so conflict resolution is trivial.

Stable branches do "fall behind" intentionally. Only qualifying changes get cherry-picked manually.

Make sense. Thank you for the explanation!