My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 2167: Merge type Rebase If Necessary should rebase for outdated parent commits as well
30 people starred this issue and may be notified of changes. Back to list
Status:  Accepted
Owner:  ----


Sign in to add a comment
 
Reported by l13uw3hu...@gmail.com, Oct 4, 2013
Affected Version:
2.7

What steps will reproduce the problem?
1. Create a repository with merge type REBASE_IF_NECESSARY
1. Upload 2 consecutive changes (A and B)
2. Modify change A, e.g. edit the commit message
3. Merge change A, now at rev 2
4. Try to merge change B at rev 1

What is the expected output? What do you see instead?
Actual output:
Change B can not be merged, because it still depends on change A rev 1. Change B can be merged after rebasing manually (using the button, or locally on my dev).

Expected output:
Change B gets rebased and rebased at once.

Please provide any additional information below.
-
Oct 4, 2013
#1 l13uw3hu...@gmail.com
Minor edit for Expected output:
Change B gets rebased and _merged_ at once.
Oct 20, 2013
#2 paf...@gmail.com
Had a similar problem with Cherry-pick strategy. Although according to the documentation this strategy should completelly ignore the parental linkage, once the dependent change was outddated (and since the submit actually created new patchset this was hapenning often), manual rebase was necessary prior the submit. It behave this way in 2.5, I didn't try it in 2.7.
The reason I'm mentioning it is that I think both these problems are caused in exact same place in the code. If this would be fixed, the overhed for administering the once-reviewed change (which is currently quite annoying) would be significantelly reduced.
Nov 5, 2013
Project Member #3 edwin.ke...@gmail.com
I'm able to reproduce this issue with the 'Rebase If Necessary' strategy on current master. The 'Cherry-Pick' strategy works fine in this case.
Status: Accepted
Nov 5, 2013
Project Member #4 edwin.ke...@gmail.com
I've written a test case that reproduces the bug:
  https://gerrit-review.googlesource.com/51390

Jan 28, 2014
#5 halcyon1...@gmail.com
We see this problem regularly in our environment, and it requires extra developer effort to rebase, when most of the time it should be automatic.
Jan 28, 2014
#6 halcyon1...@gmail.com
Note also this is still a bug as of 2.8.1
Jan 28, 2014
#7 brandon....@gmail.com
Fixing this would be really great.  I see this one regularly, even with 2.8.1.  Thanks!
Jul 16, 2014
#9 dennis.h...@gmail.com
Is there any chance to fix this bug in the next release? 
May 19, 2015
#10 duft.mar...@gmail.com
We have the same problem. Pushing two consecutive changes, then waiting a while (until something unrelated happens on the branch). Submitting the first change requires a rebase (because something unrelated did happen). The second change is now outdated and requires a manual rebase (which triggers CI builds, ...) which produces the /exact/ same result as if gerrit would allow to submit the change immediately to master and doing an automatic rebase while doing so.

I suggest that submitting a change based on an outdated patchset should be possible as long as the outdated patchset of the parent change was the one that was submitted (thus there is only one following patchset - which is the one generated by the automatic rebase). In this case, the parent change did not actually "change", thus the second change can safely be rebased on the target branch automatically.

Any comments? :) Did I get it right?
Sign in to add a comment

Powered by Google Project Hosting