| 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 |
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
Oct 20, 2013
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
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
I've written a test case that reproduces the bug: https://gerrit-review.googlesource.com/51390
Jan 28, 2014
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
Note also this is still a bug as of 2.8.1
Jan 28, 2014
Fixing this would be really great. I see this one regularly, even with 2.8.1. Thanks!
Feb 11, 2014
Added a potential fix here: https://gerrit-review.googlesource.com/#/c/54550/
Jul 16, 2014
Is there any chance to fix this bug in the next release?
May 19, 2015
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 |