How can I know in git if a branch has been already rebased onto master?

Question

This is very similar to How can I know in git if a branch has been already merged into master? but is about checking for rebased code. In the repository I am currently working on it seems that a few feature branches have been left hanging aground after their changes were rebased onto master. What is the best way for me to check that this has been done before I delete the branch?

Most of the suggestions on that branch suggest using the SHA id key of the last change on a branch to check for its presence in master. I can see that is the best way to be sure for merging but when you rebase this SHA is changed.

I have an answer that I will post too but I would like to know if people think there are better options.

Suspend

Possible duplicate of How can I know in git if a branch has been already merged into master? – Exceed

@Exceed I don't necessarily think that rebasing and merging is the same. – Wentz

No, rebasing changes the SHA key for the changeset so the majority of the answers in that question cannot work for this one. One use of rebasing is to re-write history of the changeset, that is what makes it potentially hard or impossible to work out what happened in some scenarios. That is what I am asking this question. Also rebasing seems widely used in git, so the chances of people other than myself finding repositories with abandoned branches that were rebased onto other ones seems quite high. – Suspend

@Wentz Of course they are not the same, but the true intent here is to find what was merged or not, or in other words: what is already part of the master or not. What is not part of the master will be the branches that were not merged. – Exceed

@Exceed Yes the intent is to find out what changeset that were part of a branch are now included in another branch. If those changes were merged in it is relatively easy to be certain by checking for the existence of the SHA but rebasing changes onto a branch alters the SHA from the original. More than that it is possible to alter the comments & possibly Author & Timestamps too. This question is about finding the best way to be confident about the inclusion of a change when rebasing might have corrupted the usually used meta data. That makes it very different from finding merged changes. – Suspend

git cherry, see my answer here for more details #16305074 – Somato

@AndrewC that is very helpful and the difference between 'patch id' and 'commit id' was not something I had heard of before. I can see that this would help greatly in locating any commits that did not include merge resolutions or were the result of combined commits. I do not know what the usual process is for including the answer of another question as an answer but that seems to be what we need here. – Suspend

Answer 1

In a case where the rebases are faithful to the original commit message @TafT's answer will work well. In addition, using

git log --oneline --cherry master...some-branch

will show = by every commit that has been copied exactly the same from some-branch to master.

If squashing and the like is taking place, commit messages are changed, or if your rebasing had conflicts neither solution will work. In this case I suggest the following (Checkout to detached HEAD so that we do not accidentally push this merge):

git checkout master~0
git merge some-branch

Unless your code has changed drastically, if the merge results in no change, then the branch has been rebased already. Otherwise, it obviously has not.

Crept

A comment by @AndrewC on the question explained that 'patch ids' are used by some of the cherry commands. That would make your suggestion more suitable than I first realised as it is not based on the 'commit ids' that change when you perform a rebase. – Suspend

Answer 2

Searching by the last commit message of the feature branch within the master branch's log works quite well.

On the master branch do:

 git log -i --grep="<summary>"

Where is a segment of the comment from the last commit in your feature branch. This presents you with the commit SHA for the master branch copy, the Author and Date of the commit; the last two of which are preserved by a rebase. If your Author, Date and Comments are similar then you can be confident that the change was rebased onto the branch who's log you are inspecting.

This will not work if the rebase was used to squash all the feature branch commits into a single commit on master.

There are possibly other issues with this method, please do post them in the comments or suggest better answers where you can.

Suspend

Answer 3

You can also rebase the feature branch onto the master branch. If it was already rebased, the feature branch will not have any more commits in front of master after the rebase, but point to the same commit as master. If the feature branch has master as upstream (git branch --set-upstream-to=master), you can then safely delete the branch with git branch -d feature-branch and git will make sure that there are no dangling commits.

Perambulator