1

With git cherry it is possible to check which commits have been already applied to another branch, typically the upstream. However, this returns only non-merge commits. Also git log --cherry ... excludes merge commits, since it implies --no-merges.

If a commit has been cherry-picked with -x, then the source revision is included in the commit message, so it is at least possible to git log --grep for a revision and check if it is already present.

If -x has not been used when cherry-picking, how can I robustly detect if a merge commit has been already picked to a branch?

Narcolessico
  • 1,921
  • 3
  • 19
  • 19

1 Answers1

0

However, this returns only non-merge commits

For good reason: you can't blindly cherry-pick merges, it's always cleaner and safer to cherry-pick the merged commits instead of the merged result.

Still, this is Git. You can cherry-pick the result's diffs from one tip or the other, but be aware that that's going to bake in any conflict resolutions, and those are specific to that merge, i.e. incorporating both histories since the merge base, not just one, and so not something you want to casually rebase like this.

If you've somehow found yourself backed in to having to do this anyway, it's not hard to extend what git cherry automates for you and generate patch ids for the diffs you'd have used,

git show -m $themerge | git patch-id

and look for commits in the other history with the same patch id, but I'm having a very difficult time imagining what anyone would even think they're gaining by doing this. Erasing Git's records of merges like this might not quite be up there with lying to your compiler, but it's a niche usage at best, disabling almost all of Git's content-tracking machinery and leaving you with a lot of work doing manual record keeping and manual spelunking in and deduction from those records to make up for the Git records you put so much effort into erasing.

jthill
  • 55,082
  • 5
  • 77
  • 137
  • `For good reason: you can't blindly cherry-pick merges, it's always cleaner and safer to cherry-pick the merged commits instead of the merged result.`: I am not sure why it would be cleaner/safer to work with individual commits instead of merges, if a merge introduces an atomic change? Es. in repositories where master basically has only merges and it is well defined which parent I need from a merge. When I rebase, git automatically detects merged PRs and removes them from the list. I am just looking for a way to check what git already does, without the need to actually doing it. – Narcolessico Jul 23 '21 at 08:26
  • Then look for duplicate patch-ids. – jthill Jul 24 '21 at 10:12