git diff without intermediate commits

Hello List,

I have a question regarding git diff command.

My Problem: When we work in git projects under github, we will normally create a local branch, make some changes commit it create a PR & send that for review may have to merge 'master' branch one or more times to make sure that automated build works properly after merging the latest master branch. Will enhance the PR based on review comments OR add new changes.

Assuming that my commit history is as follows:

a. commit1     <-- My local commit 1 b. merge_commit1 <- Merge commit from 'master' c. merge_commit2 .... f. merge_commit_n g. commit2  <-- My local commit 2

Now, if I issue 'git diff commit1 commit2', git will show a diff of commit1, commit2 plus the intermediate merge commits. What git does here is absolutely correct. But, my requirement is to only have the difference between commit1 & commit2 (without the intermediate merge commits).

We can definitely compare individual files between two commits in the following manner e.g., git diff commit1:file commit2:file but, if I want to get the diff for all my files from commit1 to commit2 without considering totally unrelated files from the merge commits in between commit1 and commit2, I think it is a tedious process. Correct me if I am wrong.

So, my questions are.

Is there a feature readily available in git that will compare just commit1 & commit2 without considering the intermediate merge commits?

 If the answer to the above question to is 'no', if I am providing a patch for the same for 'git diff' & 'git difftool' probably with a new command line option, would you accept it?

Thank You! Sudheer

On Thu, Mar 09, 2023 at 05:52:15AM +0000, Sudheer D wrote:

No. A diff is comparing two endpoints, without regards to the history. You can choose different endpoints, but I don't think that really helps your case (sometimes using the merge base as the preimage, which you can access via the three-dot "diff commit1...commit2" can help, but I don't think it does in your case).

We'd never say "yes" to accepting a patch without seeing it. I'm not inherently against such a feature, but I have trouble seeing how it could even be implemented. You are really asking for a diff between the state of "commit2" and "commit1 as if it had been applied on top of those merges". But there is no guarantee that commit1 can be applied there. If the merges touch some of the same lines, it won't work (and likewise, if you try to do clever things like subtracting out bits of the diff that come from the intermediate merges, it won't always work).

You can try something like:

  # use a detached HEAD for looking around; we go
  # the parent of commit2 here, which should be merge_commit_n
  git checkout --detach $commit2^

  # this may fail if commit1 conflicts with any of the merges
  git cherry-pick $commit1

  # but now we can see just the differences from commit1->commit2
  git diff HEAD $commit2

which will work sometimes, but I don't think it would be a good idea to build a feature around it.

-Peff

Jeff King <peff@peff.net> writes:

Yup, that is how I would do the comparison, if I cannot undo these "pointless merges from the upstream".

Probably.

Thanks.