Assessing about commit order in upstream Linux

Dear Git community,

Assessing about the correct order of upstream commits is essential during the backporting process, since we aim to ensure that the backporting result can be built and bisected at each commit.

However, there appear to be at least two ways to compute the relative order of "mainline" commits, specifically based on the:

 * index/position of commit summary line in the output of
   'git log --oneline --topo-order upstream/master'

 * 'git describe --contains --match="v*" <SHA1>' of each commit

I've considered both approaches equivalent, until I ran into [A-B].

Judging by the index in the 'git log' output, commit [B] seems to (topologically) come first and hence would need to be backported first:

$ git log --reverse --oneline --topo-order v4.14..v4.15 | grep -n "mm: slabinfo: remove CONFIG_SLABINFO" | cut -f1 -d: 7261 $ git log --reverse --oneline --topo-order v4.14..v4.15 | grep -n "RDMA/umem: Avoid partial declaration of non-static function" | cut -f1 -d: 7029

Judging by the version returned by 'git describe --contains', commit [A] seems to (topologically) come first due to '~93' putting it (mentally) "earlier" in the topological graph compared to '~73':

$ git describe --contains --match="v*" 5b36577109be
  v4.15-rc1~93^2~117
$ git describe --contains --match="v*" fec99ededf6b
  v4.15-rc1~73^2~56

So, the two approaches lead to different results. If you see any false assumption or mistaken belief, could you please pinpoint that? TIA.

[A] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5b36577109be
  ("mm: slabinfo: remove CONFIG_SLABINFO")
[B] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fec99ededf6b
  ("RDMA/umem: Avoid partial declaration of non-static function")