On Tue, Aug 16, 2022 at 09:14:32AM -0400, Mimi Zohar wrote:
On Tue, 2022-08-16 at 18:45 +0800, Coiby Xu wrote:
On Tue, Aug 16, 2022 at 09:59:57AM +0200, Greg KH wrote:
Hopefully the git ids can be stable when they are merged to a maintainer's tree.
A missing Ack was added to one of the commits resulting in a forced rebase.
I notice the commit ids of these patches in current next-integrity tree are still different from Linus's tree. It seems there is no way to avoid manually backporting a patch for similar cases unless the commit ids are automatically fixed when Linus merges the patch or we could match a commit by its subject.
After "fixing" the topic branch merge message, I forgot to push it out to the next-integrity branch. (Will be fixed shortly.) Other than the merge message commit itself, the commits in Linus' tree and the next- integrity branch are the same. The pull request was based on the integrity-6.20 tag.
Tip of linux-integrity/next-integrity: $ git log 1d212f9037b0 | head -2 commit 1d212f9037b035e638d53834bfe8d3094ca1d04c Merge: c808a6ec7166 0828c4a39be5
Tip of the my local branch and what's in Linus' branch: $ git log 88b61b130334 | head -2 commit 88b61b130334212f8f05175e291c04adeb2bf30b Merge: c808a6ec7166 0828c4a39be5
The pull request tag: $ git log integrity-6.20 | head -2 commit 88b61b130334212f8f05175e291c04adeb2bf30b Merge: c808a6ec7166 0828c4a39be5
Thanks for the explanation! Previously I thought the commit ids are different because Linus may have picked up the patches from the next tree and the git ids can only be determined in the last moment. But according to [2][3], Linus always merges a signed tag from a subsystem maintainer and unlike cherry-pick-up a merge could preserves the commit ids so a subsystem maintainer could know stable commit ids.
[2] https://www.spinics.net/lists/newbies/msg63520.html [3] https://docs.kernel.org/maintainer/pull-requests.html
Mimi