20

I've made several commits on my branch and now I was to see the changes from when I branched from master. However not the current master as that now has other branches merged in since I originally branched off it.

Similar to Show all commits in a git branch since original branching point from master but that is about the log.

I did try

git diff  --boundary master..

but I still see a lot more changes than just mine.

EDIT: I'm really hoping for a way that doesn't require any knowledge of SHA's or how many commits were made. If I don't need them I can automate and teach and automate and alias it more easily and trouble-free.

git diff my_branch_name...master

seems close but is not correct.

Community
  • 1
  • 1
Michael Durrant
  • 93,410
  • 97
  • 333
  • 497

3 Answers3

35

As Jonathan Brink already noted, it sounds like you want to compare the version stored under the merge-base commit to the version at the tip of your own branch.

Using git merge-base --fork-point is usually overkill (and is not available on older versions of git, before git 1.9). It handles cases where the other branch has itself been rebased, so if that hasn't happened, you can stick with the simpler three-dot syntax from gitrevisions:

git diff master...my_branch_name

which (as you noted in a comment) can also be written using either HEAD or simply the empty string at the end:

git diff master...

When you use three dots, git diff finds the1 merge-base between the left and right side commit SHA-1s (as obtained from the names, or defaulting to HEAD) and substitutes that in for the left-side SHA-1. The right-side SHA-1 (as resolved from the name) remains intact.

Note that this is different from the two-dot syntax, and that git diff takes over both syntaxes (syntaces? no, syntaxes) so that neither one has its more-usual gitrevisions meaning.

1If there's more than one merge base, it just picks one of them. An actual git merge will (if you use the default "recursive" strategy) merge two "best" merge-bases to get a "virtual merge base", then use that to merge into your current HEAD commit. This case is pretty rare though.

Community
  • 1
  • 1
torek
  • 448,244
  • 59
  • 642
  • 775
  • Would this show uncommitted changes on the `my_branch_name` as well? – alper Jul 23 '21 at 09:28
  • 1
    @alper: uncommitted changes aren't in Git. Having Git compare two commits that *are* in Git therefore cannot show them. You can have Git compare one commit that *is* in Git, against some other set of files that *isn't* in Git; this will show whatever is different between the committed files and the uncommitted, not-in-Git files. – torek Jul 23 '21 at 09:30
  • 1
    I'll repeat this, because it's **crucial** to using GIt: *uncommitted files are not in Git* and are therefore not on *any* branch. – torek Jul 23 '21 at 09:31
9

Use merge-base to determine the sha where the fork occurred, and pass that to diff:

git diff `git merge-base --fork-point master`

--fork-point
Find the point at which a branch (or any history that leads to <commit>) forked from another branch (or any reference) <ref>. This does not just look for the common ancestor of the two commits, but also takes into account the reflog of <ref> to see if the history leading to <commit> forked from an earlier incarnation of the branch <ref> (see discussion on this mode below).

You could wrap this up in an alias like this:

git config --global alias.sincemaster '!git diff `git merge-base --fork-point master`'
Mr Lister
  • 45,515
  • 15
  • 108
  • 150
Jonathan.Brink
  • 23,757
  • 20
  • 73
  • 115
1

If you know the sha value of the commit where the two projects diverged you can simply run: git diff <sha>

Ivar
  • 5,102
  • 2
  • 31
  • 43