0

When performing a code review my approach is to use meld to view the changes to the branch:

Step 1. Using git log to find the sha1's of the first and last commits on the branch

git log --graph --oneline --all

This will give something like:

    * fffffff Another commit to HEAD
    * eeeeeee A commit to HEAD
    | * ddddddd The last commit on branch MY_AWESOME_CHANGE
    | * ccccccc Some work
    | * bbbbbbb First commit on branch MY_AWESOME_CHANGE
    |/  
    * aaaaaaa Updated comments to explain aggregation of External Data

Step 2. Use git difftool to launch meld to view the changes

git difftool aaaaaaa ddddddd

My question is: Is there a better way to go about step 1? The following question provides a way to find the branch start point: finding-a-branch-point-with-git. I can then use "git log" to find the sha1 for the last commit on the branch:

git log -1 MY_AWESOME_BRANCH

But it seems overkill and I wonder if I'm missing something simpler.

Community
  • 1
  • 1
Andy Longwill
  • 624
  • 9
  • 25

2 Answers2

4

You can use the ... (triple-dot) syntax to git diff or git difftool, as in:

git difftool master...experiment

What this does is to show you the difference between:

  • The merge base of master and experiment
  • ... and experiment

The meanings of .. and ... are different for git log and git diff - this other answer of mine has some diagrams that show the difference.

Community
  • 1
  • 1
Mark Longair
  • 446,582
  • 72
  • 411
  • 327
0

If you're on HEAD, then 

git merge --no-commit --no-ff MY_AWESOME_CHANGE

will show you all the changes which would be merged onto your HEAD, and will update your working copy appropriately, but won't actually commit the merge.

Graham Borland
  • 60,055
  • 21
  • 138
  • 179