How does git --no-merged option work

Question

How does the git branch -r --no-merged work?

Does it check to see if all commits in one branch already exist in the original parent branch?

And what about cherry picks? Is it smart enough to say that a commit from 1 branch has already been cherry picked back into the original parent branch?

And if a branch has already been merged and new commits have been added will it pick that branch up as not being merged?

Answer 1

Well, that comments from @Hasturkun says it all to be honest, but you have 3 questions:

1. Does it check to see if all commits in one branch already exist in the original parent branch?

Not trying to be repetitive @Hasturkun quote says: "Only list branches whose tips are not reachable from the specified commit".

In this specific case think of the git tree of commits as a tube/underground map. You can only travel backwards from one node/station to the other.

master    : - - - -0 
                    \   
branchA   :          E - - - - F - - - - G

If on master you run git branch --no-merge and taking the manual page definition? Can you reach G (the tip of of branchA) from master's HEAD, commit 0? No you can't, so branchA will be listed as a non-merged branch.

How about if you run git branch --no-merge from the HEAD of branchA(commit G)? Will master be a non-merged branch? No, it is considered a merged branch, trivial to understand why given the example before.

How about this example?

master    : - - - -0
                    \   
branchA   :          E - - - - F - - - - G - - - Z
                               \                /
branchB   :                     Y - - - W - - -

Output of running git branch --no-merged in all 3 branches:

master
  branchA
  branchB
branchA (nothing)
branchB (nothing)

2. And what about cherry picks? Is it smart enough to say that a commit from 1 branch has already been cherry picked back into the original parent branch?

Cherry-picks create a completely different commitId, so I only use them when I really have to. Since it creates a completely different commit, the trees will differ:

Look at this experiment I just did, consider master and branchA the same:

Experience 1) Using merge

(master)$ touch empty && git add . && git commit -am "File Added"
(master)$ checkout branchA
(branchA)$ git branch --no-merged
  master
(branchA)$ git merge master
(branchA)$ git branch --no-merged
  // outputs nothing

Experience 2) Using cherry-pick

(master)$ touch empty && git add . && git commit -am "File Added"
(master)$ checkout branchA
(branchA)$ git branch --no-merged
  master
(branchA)$ git cheery-pick <commitID from above>
(branchA)$ git branch --no-merged
  master

3. And if a branch has already been merged and new commits have been added will it pick that branch up as not being merged?

Yes, because of all stated above.