I have branches where
git branch -d some_branch
returns
branch 'some_branch' is not fully merged.
But
git diff ...some_branch
is empty.
In other words, (as I understand) there are no changes that exist in "some_branch" that I don't have in the current. But yet it's not "fully merged".
Am I correct is assuming the only way this can happen is a rebase of the current branch? In which case, there might be a disagreement of history, but no disagreement of code.
Further, this seems to be always the result of an intentional act.
Therefore I should always be safe in deleting a branch if git diff ...some_branch
is empty. Is that correct?
When git complains about "not fully merged" it is talking about the relationships of the commits, not about the content of the files.
If you have one base commit and on top of this two different commits introducing the same changes, then the diff between both is empty. But nevertheless your branch has "two heads" and is therefore "not fully merged".
In your situation probably your local head is at
B
while your upstream head is atB'
.If you delete your local branch your local commit will not be part of your upstreams history. Therefore the commit and all it's meta data (like author, date,...) will be lost. - That's the reason for the warning.