4

To do code review, I often make a git difftool hash_of_parent_of_first_commit_in_branch last_commit_in_branch of a feature branch. The feature_branch was created from its source (let's call it master branch) and work was done on it. But in the middle of this time, the master branch received some commits, and these commits were merged in the feature_branch.

To clarify, if I was using git log, this command would be simple: git log feature_branch ^master (maybe with a --no-merges or not, depending on the case). With this I would have the master commits filtered out of the feature_branch.

I did some research but was not able to figure out how could I achieve this. Maybe using cherry-pick? Any ideas on how could I achieve something similar on the diff/difftool command?

jademcosta
  • 1,528
  • 15
  • 23

1 Answers1

4

Firstly, you can get a list of suitable commits like so:

git rev-list --reverse --no-merges feature_branch ^master

this gets every non-merge commit on feature_branch that isn't reachable from master. The reverse puts them in chronological order, suitable for application.

Secondly, you can cherry-pick these to a temporary branch:

git branch review $(git merge-base feature_branch master)
git checkout review
git rev-list --reverse --no-merges feature_branch ^master | xargs git cherry-pick

and then your review will be on

git diff $(git merge-base feature_branch master)..review

Note the xargs may make it hard to resolve cherry-pick problems interactively. You could write a wrapper script to do all this using a for loop instead of xargs to keep everything connected nicely to the terminal though.

Useless
  • 64,155
  • 6
  • 88
  • 132
  • Accepted because it's the right answer! Just to help others, when the merge from master to feature_branch is made in the middle of development process, the next commit on feature_branch cannot be fully "detached" from the changes inserted by the merge. (It was obvious but I didn't noticed) So, although this is the correct answer, and it may work if the files people changed are different, the "wisdom of the ancient gods" is right: small pull requests save a lot of time. Rebase, when correctly (and when can be) applied, saves a *lot* of time. – jademcosta Feb 10 '15 at 16:26