How do I find common files changed between git branches?

Question

I have an upstream repository with some changes. I have local changes I want to rebase onto the upstream changes. I want to know what files I've changed locally have also changed upstream so I can check any automatic merging. Alternatively, I'd like to manually do any merges during the rebase.

Answer 1

Listing changed files

Since a rebase/merge can be time-consuming, it's best to avoid doing an unnecessary one. There are a variety of ways to see what's been changed, depending on what sort of information you need.

If you're interested in knowing per commit what files have changed, I'd suggest git-log:

git log [--pretty=<format>] --name-only <common-branch>..<local-branch>

You can use the --pretty option to get the header information you need; <format> can be a variety of choices, including a custom string with fields - see the man page for more information.

The --name-only option is actually being passed through to git-diff, so if you don't care about per-commit results, you can go straight to the source:

git diff --name-only <common-branch> <local-branch>

Note that the branches are specified differently for the two commands.

You can apply this to the upstream changes as well, changing <local-branch> to <upstream-branch>, and end up with two lists of files. I'll leave it up to you to figure out how you want to compare them, though the -f option of grep can be handy...

Manual merges

Autocracy beat me to this. If you've done some smart processing based on output of git-log you could edit only the commits you saw had overlapping file changes. If you were merging rather than rebasing, you'd use the --no-commit option.

See also the configuration section of the git-merge man page. You might want to set merge.conflictstyle to diff3, so that you can see the original text as well as the changes on either side.

If you're really desperate to suppress all attempts at automatic conflict resolution, I believe you could plug in a dummy mergetool (via merge.tool and mergetool.cmd) that does nothing and returns failure.

Having said all of this, I should also say that in my experience with git merges, I have seen plenty of conflicts but cannot remember a single incorrect automatic merge. I personally trust it's merging capabilities. Checking up on it after should really be plenty.

Answer 2

Expanded a bit: for you first part of the question, make a new branch, automatically do the rebase there, and then compare to your working copy.

git branch workBranch
git commit #throw your locals into your own branch for a brief moment
git branch testBranch
git rebase otherBranch
git diff workBranch

You might also get away with just doing a "git diff origin/branchToMerge"

For the interactive part:

git rebase --interactive.

Set all the commits to "Edit" and you'll be taken through each of them one-by-one giving you a chance to see everything done for that commit and edit to your heart's content.

EDIT to answer comment

OK, for strictly seeing changed files, do:

git log a0a0a0..b1b1b1 --name-only --pretty=oneline | egrep -v '^[a-f0-9]{40} ' | sort | uniq > lista
git log a0a0a0..c2c2c2 --name-only --pretty=oneline | egrep -v '^[a-f0-9]{40} ' | sort | uniq > listb
cat lista listb | sort | uniq -d

That bit of shell kludgery will show you only files that changed in both logs. For a0a0a0, use your common point. Replace the b1/c2 strings with the tips of the two diverging branches.