3

I'm trying to do a code review on a feature branch that has changes from the mainline merged in at several points. I make this question's title intentionally very similar to Show non-merge differences for two commits in git but I'm not satisfied with the answers.

My problem is that the feature branch has multiple commits on same files and some changes are reverted or changed again.

One of the answers in above question is to use git log --no-merges -p branch-start..branch-end. I find that the resulting diff file still mentions changes in files that were not part of the real work on the branch.

Another suggestion - to use --first-parent - comes closer, but I get a diff that contains the same file multiple times, once for each commit. As I'm not interested in the history of the change, just the final state, this doesn't allow me to have the initial state on the left side and the final state on the right side of the diff viewer.

BTW, I'm using ReviewBoard to import the diff and do the review.

Community
  • 1
  • 1
kresho
  • 136
  • 1
  • 8
  • Have you tried the rebase approach, http://stackoverflow.com/a/4555193/23118? I was about to write an answer suggestion the exact same thing. If this does not show you what you want, then you must explain more. – hlovdal Mar 19 '14 at 22:18
  • The problem with the suggested solution is that it does not exclude merge commits, and git rebase does not accept `--no-merge` or `--first-parent` parameters. – kresho Mar 20 '14 at 08:43
  • I do not quite understand. If feature_branch has several merges from mainline_branch and you rebase feature_branch to be on top of mainline_branch, then all of those merges should disappear! But in any case, after the rebase there is nothing stopping you from doing an interactive rebase where you delete all those merge commits you do not want to include. – hlovdal Mar 20 '14 at 08:55
  • Ok, I wasn't aware of the disappearing merges. I'll try that. I have considered the interactive rebase, but it is difficult to determine which of the commits come from which branch. – kresho Mar 20 '14 at 10:55
  • I tried the rebase approach. I'm not sure if I'm doing something wrong here, but rebase wants to re-apply many commits from other feature branches that were merged into the mainline branch before it was merged into the feature branch that I want to review. Also, I'm getting a lot of conflicts. This may be expected, but it looks too work-intensive for me right now. I have not completed the process, but I suspect that after the rebase, the original feature branch would disappear, and I'd need more magic to restore it. – kresho Mar 21 '14 at 14:58
  • One solution is to use the output of `git log` to cherry-pick the appropriate commits onto a temporary branch, and then perform a `git diff` on that branch. See: [git: cumulative diff with commit-limiting](http://stackoverflow.com/q/25403705) – TachyonVortex Aug 21 '14 at 15:14

0 Answers0