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
--
Best regards,
Coiby
