5 ms·
That's because you are not supposed to rebase other people's code on top of a changed base. That can effectively modify the behaviour of their code change. So i
by mh8h 7y ago
That's because you are not supposed to rebase other people's code on top of a changed base. That can effectively modify the behaviour of their code change. So it's good that the resulting commit won't be signed anymore.
And if you are rebasing your own code, then you can sign it again.
- gus_massa 7y agoWhat about cherrypicking bug fixes to old versions?
- jimktrains2 7y agoCherry picking creates a new commit.
- gus_massa 7y agoThe cherry picked comment usually has the same author and date that the original commit. (Note that rebasing also creates a new commit.) One of the latest commits backported to Linux 4.9.something https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.9.y&id=8d8276867b5ac539f1d6e166a028b51c8b1ceda8 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... Cherrypicked from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=master&id=060423bfdee3f8bc6e2c1bac97de24d5415e2bc4 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... Note that the changes are identical, just add ` &&ret` twice, but the line numbers have changed. Also, the cherrypicked version has an additional `Signed-off-by: `.