Changes Stuck in "Submitted, Merge Pending" Status

[nnutter]

I have a change that is stuck in a "Submitted, Merge Pending" state but I can't figure out why.  No comment has been added suggesting a merge has been attempted yet.  The parent commit as shown in Gerrit says "(MERGED)".  I tried rebasing my change locally and pushing but the push gets rejected with "(no new changes)".  I wasn't able to find any information that seemed to help from searching so I am hoping there is some way to get more information from Gerrit or to maybe re-trigger the submit or whatever.

I am (still) basically testing Gerrit before our team starts using it.  I am currently running 2.6-rc4.

[nnutter]

On Wednesday, September 18, 2013 10:02:29 AM UTC-5, nnutter wrote:

I have a change that is stuck in a "Submitted, Merge Pending" state but I can't figure out why.  No comment has been added suggesting a merge has been attempted yet.  The parent commit as shown in Gerrit says "(MERGED)".  I tried rebasing my change locally and pushing but the push gets rejected with "(no new changes)".  I wasn't able to find any information that seemed to help from searching so I am hoping there is some way to get more information from Gerrit or to maybe re-trigger the submit or whatever.

I am (still) basically testing Gerrit before our team starts using it.  I am currently running 2.6-rc4.

As usual, I find something shortly after giving up.  Is the way to "re-trigger the submite" to update the status in the database by hand?

UPDATE changes SET status = 'n' WHERE change_id = X;

[Shawn Pearce]

Usually you can just click the "Submit Patch Set N" button on the web
UI to make it try the submit again.

[Nathan Nutter]

I also tried that but had no change.

[Blewitt, Alex]

I have found the times when this happened is when master has moved on but the code change has already made it into the branch somehow (i.e. direct push behind the server). Gerrit keeps trying to do a merge and conflicting with itself, so the merge doesn't go through. I suspect in those cases doing a manual fixup of the repository behind the scenes confuses Git and so it thinks that a change should be mergable but doesn't consider that it might already be present.

In these cases, after manually verifying that the change is indeed present (or otherwise merged) I've updated the table by hand to say that it has been.

Alex

[Nathan Nutter]

Wouldn't a `git pull --rebase && git push origin HEAD:refs/for/master` "fix" that? (For me `git pull --rebase` is a no-op.)

Why wouldn't Gerrit post a comment to the changeset saying the merge failed?

Thanks for both responses so far. I am definitely interested in what the right way to fix this problem is and I would like to provide any additional information that is needed.

[Alex Blewitt]

On 18 Sep 2013, at 20:02, Nathan Nutter <i...@nnutter.com> wrote:

> On Sep 18, 2013, at 11:44 AM, "Blewitt, Alex" <Alex.B...@gs.com> wrote:
>
>> On Sep 18, 2013, at 10:53 AM, Shawn Pearce <s...@google.com> wrote:
>>
>>>> Usually you can just click the "Submit Patch Set N" button on the web
>>>> UI to make it try the submit again.
>>>
>>> I also tried that but had no change.
>>
>> I have found the times when this happened is when master has moved on but the code change has already made it into the branch somehow (i.e. direct push behind the server). Gerrit keeps trying to do a merge and conflicting with itself, so the merge doesn't go through. I suspect in those cases doing a manual fixup of the repository behind the scenes confuses Git and so it thinks that a change should be mergable but doesn't consider that it might already be present.
>>
>> In these cases, after manually verifying that the change is indeed present (or otherwise merged) I've updated the table by hand to say that it has been.
>
> Wouldn't a `git pull --rebase && git push origin HEAD:refs/for/master` "fix" that? (For me `git pull --rebase` is a no-op.)
>
> Why wouldn't Gerrit post a comment to the changeset saying the merge failed?

You get the merge failed when a conflict occurs. If the merge couldn't be processed because Gerrit thinks a dependency hasn't been merged it stays in that state (assuming the dependency will be subsequently merged). If that condition doesn't arrive then it can remain in that limbo state.
>

Alex

[Nathan Nutter]

OK, I figured out how to get more data in text form. I hope this helps others understand my confusion.

The changeset in question is 43:

$ ssh -p 29418 apipe-review.gsc.wustl.edu gerrit query 43 | grep status
status: SUBMITTED

Specifically, it's 43/1:

$ git fetch origin

$ git fetch origin refs/changes/43/43/1
From ssh://apipe-review.gsc.wustl.edu:29418/git-gerrit
* branch refs/changes/43/43/1 -> FETCH_HEAD

Here you can see that origin/master is the only dependency of the commit in question:

$ git log -n 2 --oneline --decorate FETCH_HEAD
819df61 switch to CMake
e33e763 (tag: v0.001, origin/master) missed reference to old name

This all agree with the state Gerrit is showing me, e.g. the only "Depends On" is "MERGED".

So if there is no message about a merge conflict and it's only dependency is in fact merged into master already then why else might my commit be stuck?

[Nathan Nutter]

On Sep 18, 2013, at 3:04 PM, Nathan Nutter <i...@nnutter.com> wrote:

> OK, I figured out how to get more data in text form. I hope this helps others understand my confusion.
>
> The changeset in question is 43:
>
> $ ssh -p 29418 apipe-review.gsc.wustl.edu gerrit query 43 | grep status
> status: SUBMITTED
>
> Specifically, it's 43/1:
>
> $ git fetch origin
>
> $ git fetch origin refs/changes/43/43/1
> From ssh://apipe-review.gsc.wustl.edu:29418/git-gerrit
> * branch refs/changes/43/43/1 -> FETCH_HEAD
>
> Here you can see that origin/master is the only dependency of the commit in question:
>
> $ git log -n 2 --oneline --decorate FETCH_HEAD
> 819df61 switch to CMake
> e33e763 (tag: v0.001, origin/master) missed reference to old name
>
> This all agree with the state Gerrit is showing me, e.g. the only "Depends On" is "MERGED".
>
> So if there is no message about a merge conflict and it's only dependency is in fact merged into master already then why else might my commit be stuck?

I tried "UPDATE changes SET status = 'n' WHERE change_id = X;" but re-submitting after doing that just put it back into the limbo state. I ended up just pushing the commit to master manually, i.e. "git push origin 819df61:master" and then Gerrit saw it as merged. I had to do the same thing for the second commit, one descended from 819df61, but two other later commits had no problem.

Thanks to Alex and Shawn for taking interest in this. I hope this info might help others in the future.

[yu dong]

I had the same problem of "Submitted, Merge Pending" without any dependency or conflict. Quick fix is to go through all open items and see if there is any other commit in "Submitted, Merge Pending" status. If yes, just abandon them all.

Then git commit --amend -m "your original comments" and git push again, this time you can have your fix merged.

[Oswald Buddenhagen]

On Fri, Feb 27, 2015 at 11:30:58AM -0800, yu dong wrote:
> On Wednesday, September 18, 2013 at 8:02:29 AM UTC-7, nnutter wrote:
> > I have a change that is stuck in a "Submitted, Merge Pending" state but I
> > can't figure out why. No comment has been added suggesting a merge has
> > been attempted yet. The parent commit as shown in Gerrit says "(MERGED)".
> > I tried rebasing my change locally and pushing but the push gets rejected
> > with "(no new changes)". I wasn't able to find any information that seemed
> > to help from searching so I am hoping there is some way to get more
> > information from Gerrit or to maybe re-trigger the submit or whatever.
> >
> > I am (still) basically testing Gerrit before our team starts using it. I
> > am currently running 2.6-rc4.
> >

we have/had the same problem with gerrit 2.7.

i cherry-picked a bunch of fixes from 2.8 and it seems to be stable
for a few weeks now, so i'm assuming i got the right one(s). see
https://codereview.qt-project.org/107342 and subsequent changes.

> I had the same problem of "Submitted, Merge Pending" without any dependency
> or conflict. Quick fix is to go through all open items and see if there is
> any other commit in "Submitted, Merge Pending" status. If yes, just abandon
> them all.
>

that seems very unclean, and at this point unnecessary.

[yu dong]

Thanks, that's really helpful. 

[Dave Borowitz]

FYI, since 2.10 or so setting the log level to DEBUG/FINE or higher will give detailed logging information about the merge attempt in the server logs. You can even do this in a live server:

https://gerrit-review.googlesource.com/Documentation/cmd-logging-set-level.html

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.