************************************************************
***** NOTE: THIS BUG TRACKER IS FOR GERRIT CODE REVIEW *****
***** DO NOT SUBMIT BUGS FOR CHROME, ANDROID, INTERNAL *****
***** ISSUES WITH YOUR COMPANY'S GERRIT SETUP, ETC. *****
***** THOSE ISSUE BELONG IN DIFFERENT ISSUE TRACKERS! *****
************************************************************
Affected Version: 2.2.2.1, 2.3, 2.4
What steps will reproduce the problem?
1.Create a repo
2.Create a branch named r10 of master
3.Push different changes to master and the branch for some days
4.Merge r10 to master
5.Push Merge to gerrit for review
What is the expected output? What do you see instead?
Expect output: Only the different files listed for review
Instead: All the files are listed with marked New File
Current Gerrit (>=2.2) will show NEW files for merge commits some time,
base on our investigation it more likes a UI problem because it's no
problem with actual git data after submit.
But we still wonder when this UI bug can be fixed well.
This happens when there are multiple merge bases. jgit doesn't know how to
create a merge in this case and punts. I'm not sure how we should best
handle this situation - the ideal fix is to teach jgit to handle multiple
merge bases.
@bklarson: Aren't all merges with multiple bases (isn't that what Merge
means)? Do you mean there are more than 2 bases? In our case, the merge
commit has only 2 parents, and the two do have a common ancestor. I may be
misunderstanding your terminology -- do you have an example that might
cause something like this? And possibly a workaround that we can be aware
of so that we can avoid this situation in the future?
merge base is like CVS/SVN most recent *common* ancestor or parent. All
merges can have one or more parents. A fast-forward merge has one parent. I
am having RecursiveMerger reviewed after which we can change Gerrit to sue
that merger instead of Resolve as a default. Then multiple base "Git"
merges presented to Gerrit might look better.
