I work in a large software team doing large monthly releases. We work on a branch to release model (see diagram).
This model solves a lot of problems, but has some risks to manage. When I go to release branch 1.1 to production, I need to check that all the commits in 1.0 are in 1.1.
I can do this with the following command:
git log --cherry-pick --right-only --pretty="%h %ce %B" --no-merges release/1.1/master...release/1.0/master > missingcommits.log
Then I go an email this list to each of the developers concerned, and ask them to just do a careful second check.
This works fairly well, but I'm concerned about it picking up some false positives.
Now of course if you have checked in the same code in two different branches with two different commits, then this will fall afoul of this scan.
In theory, if you have cherry-picked your commit from 1.0 to 1.1 - then it should not show up in this scan (ie the same commit is in both branches).
Now my code works fine. Ie code in one branch, I cherry pick across, and then it doesn't show up in this scan. So I think it should work.
When I send the email out to the developer with just their 'missing commits in the new release branch', what I get is some of the developers coming back to me and saying:
No I definitely did a cherry pick to move my code over.
Now this could be
(a) defensive behaviour, or
(b) a cherry-pick gone wrong,
(c) my misunderstanding of git, or
(d) a genuine problem with this process.
My question is: Will git log --cherry-pick --right-only --no-merges ignore all commits correctly cherry-picked between branches?