1

I am using this below command to see the list of commit hashes which have not been cherry picked from branch dev to main, since the main branch creation date from dev branch,

git log --reverse --left-only --cherry-pick --oneline dev...main --since 24-oct-2019 --pretty='format:%H    %ae'

Output is like,

6c4176c3e621ef9b83ccb4ff7635f0bd9ecd8d5c    a@xyx.com
91af2d1165d5b561af68824df37b07a520c5eb2f    b@xyx.com
a19a8eca5c5fe388a9ae9ce67f5f3592b9662012    a@xyx.com
...

However, I am seeing that some of the CLs are showing in the list which already have been cherry-picked.

Why are they showing in the list?

Sazzad Hissain Khan
  • 37,929
  • 33
  • 189
  • 256
  • Run `git rev-list --left-right --cherry-mark dev...main` and find commits that you think *should* be marked but aren't. Then run `git show | git patch-id` for each such pair of commits and see if the patch-IDs match (they shouldn't; if they do, something is seriously wrong). From there, it should be possible to figure out *why* the patch IDs do not match, which will answer the question. – torek Mar 09 '20 at 08:55
  • @torek I have done what you suggest for couple of CLs, which shows different patch ids. But the CL still appearing in the list. :( – Sazzad Hissain Khan Mar 09 '20 at 09:05
  • 1
    If the patch IDs differ, the patches are not considered to be cherry-picked. If they *were* cherry-picked, there must have been a conflict, resolved by changing the patch. (So, now the patches don't match which means the commits are not cherry-pick-equivalent any more.) – torek Mar 09 '20 at 09:06
  • @torek thanks for the info, but I see Gerrit showing those pair as cherry-picked list and what are the possible causes of such confusing states do you think? patch ids won't match even if cherry-picked with manual merge conflict resolution? – Sazzad Hissain Khan Mar 09 '20 at 09:12
  • 1
    Gerrit has its own mechanism, using Gerrit's IDs. This is not related to what Git does (other than, the Gerrit ID must be stored somewhere). (The fact that resolving merge conflicts changes the Git patch ID is *why* Gerrit uses its own ID, or at least, part of why.) – torek Mar 09 '20 at 09:19
  • That means there is no way that solves my problem. I need to check all pairs of CLs manually? :( @torek – Sazzad Hissain Khan Mar 09 '20 at 15:18
  • That, or, invent your own patch-tracking ID, which you must then store somewhere (e.g., in a commit message or a `git notes` note), similar to what Gerrit is doing. – torek Mar 09 '20 at 17:59

0 Answers0