1

When pulling and resolving conflicts I have an instance where I can review all the changes and commit my conflict resolution.

When there are no conflicts, I want to avoid automerging and review the differences between the changes I did and the changes I'm pulling before merging the changes.

Is it possible to review all the changes (difference between the changes I did and what is on the branch I want to pull) when there are no conflicts?

charlieme
  • 1,014
  • 7
  • 16
  • Does this answer your question? [Comparing two branches in Git?](https://stackoverflow.com/questions/9834689/comparing-two-branches-in-git) – Daniel A. White Mar 07 '20 at 01:50

2 Answers2

3

I see two options. First I'll give one that answers your question literally as asked, but honestly it's not what I'd recommend. So then I'll give a solution I would consider using instead...

To avoid the merge...

You can use fetch instead of pull. The whole point of pull is to be a shortcut that fetches and then does the merge automatically, so if you don't want the merge you don't have to pull. Then you would refer to the other branch using your remote tracking ref (e.g. something like remotes/origin/other_branch when examining other_branch).

But it's not clear to me what exactly you would diff in that case. Just diffing the branches isn't going to directly tell you what you want to know.

You could look at "their changes" by

git diff $(git merge-base remotes/origin/other_branch HEAD) remotes/origin/other_branch

and "our changes" by

git diff $(git merge-base remotes/origin/other_branch HEAD) HEAD

but then you'd essentially have to perform the merge in your mind to understand the result. So...

What you can do instead...

It sounds like you really want to avoid the commit of the merge, not the merge itself. (This is more akin to what happens when there's a conflict.) So

git pull --no-commit

Then examine the result and decide whether to edit it, commit it, or throw it out.

Even that isn't really necessary to do every single time, because a merge (as long as it hasn't been pushed) can be easily undone. So what I'd do is, let the merge happen. Examine the outcome with something like

git diff HEAD^

If you don't like the result, you can

git reset --hard HEAD^

and then perhaps rerun the pull (or just the merge) with the --no-commit option.

Mark Adelsberger
  • 32,904
  • 2
  • 24
  • 41
2

When there are no conflicts, I want to avoid automerging and review the differences between the changes I did and the changes I'm pulling before merging the changes.

It's better (as in safer, and easier, and faster) to just git show -m after the merge, that will show you the two sets of actually-merged changes one after another. If you're being properly paranoid, and this question shows you are, you'll want to do that anyway after every merge to check that you haven't brought in any changes you didn't notice, along with a git show --cc to check whether you goofed any merge conflicts.

That way you're checking your actual work.

If you don't like what you see, as Mark Adelsberger points out, git reset --hard @^, it's that easy.

jthill
  • 42,819
  • 4
  • 65
  • 113