My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 1374: Push Merge leads to files to be regarded as new
18 people starred this issue and may be notified of changes. Back to list
Status:  New
Owner:  ----


Sign in to add a comment
 
Reported by j...@rbcon.com, May 7, 2012
************************************************************
***** 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

Please provide any additional information below.
Take http://reviews.cloudfoundry.org/#/c/5120/ for the bug reference
May 7, 2012
#1 j...@rbcon.com
I also tested it on 2.1.7, the issue is different with above, the commit will not display any changes there when review. 

So I guess higher version Gerrit(>=2.2) is try to fix the legacy problem in 2.1.7 but not good enough.
May 7, 2012
Project Member #2 bklarson@gmail.com
Not quite - Gerrit didn't show any diffs for merge commits before 2.2ish.
May 9, 2012
#3 j...@rbcon.com
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.
May 9, 2012
Project Member #4 bklarson@gmail.com
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.
Jun 21, 2012
#5 jhans...@myyearbook.com
This still occurs on 2.4.1.

@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?
Jun 21, 2012
Project Member #6 bklarson@gmail.com
@jhansche - this is the best example I could find: http://codicesoftware.blogspot.com/2011/09/merge-recursive-strategy.html.  Unfortunately I'm not enough of a git expert to give a better answer or implement recursive merging in jgit.

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=380314.
Oct 16, 2012
#7 georgey21
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.
Sign in to add a comment

Powered by Google Project Hosting