Issue 1994: Code review diffs for subtree merge strategy merges are noisy or wrong
Status:  New
Owner: ----
Reported by dpcarrin...@gmail.com, Jul 3, 2013
Affected Version: Gerrit 2.5.2

What steps will reproduce the problem?
1. We are using the git-subtree family of commands which have been part of git since git 1.7.11

2. I created two repositories, one named 'castle', and one named 'walls', with at least one commit in each. I used

git fetch GERRIT:sandbox/walls master:walls_branch
git subtree add --prefix=walls --squash walls_branch

to add this as a subtree to the 'castle' repository.

3. Later, after making more changes to 'walls', and other changes in 'castle', I brought in those changes with a subtree merge:

git fetch GERRIT:sandbox/walls master:walls_branch
git subtree merge --prefix=walls --squash walls_branch

4. This step creates two commits; one commit contains only the 'walls' directory (which contains only the contents of the 'walls' repository); it is the second parent of a merge commit which I then push to Gerrit:

git push origin HEAD:refs/for/master

What is the expected output? What do you see instead?

On the code review page, I see a large number of changes. Some changes are clearly the result of doing (some equivalent of)

git diff-tree --name-status HEAD HEAD^2

This is a problem because (almost) no path that exists in 'walls' exists in 'castle' -- all paths from 'walls' instead are under 'walls/...'. So, it lists a large number of deletions.

The exceptions to the 'all paths' rule are that there might be files at the root directory of both 'castle' and 'walls' with the same name - so a Makefile would not show up as deleted in such a case. (But, it might show as modified.)

Please provide any additional information below.

While (I think) there's no commit metadata which would let you determine for certain that a merge commit was created by the subtree merge strategy, it would at least be helpful to see the diffs from one side of the merge separately from the diffs on the other side of the merge.

Also, the severity of this issue scales with the size of the subtree...
Aug 20, 2013
#1 dpcarrin...@gmail.com
One possible resolution would be to add "Parent 1", "Parent 2", ... options to the "Old Version History" dropdown above the diff list. That way, I could select "Parent 1" to see the changes between the uploaded merge and its first parent commit, or I could select "Parent 2" to see the changes between it and its second parent.