| Issue 1271: | Missing Blob error with submodules. | |
| 14 people starred this issue and may be notified of changes. | Back to list |
Affected Version: 2.2.2.1 and 2.3-rc0 What steps will reproduce the problem? 1) Check out code from Gerrit head and update submodules 2) Make submodule change 3) Push submodule change 4) Make supermodule change 5) Push supermodule change 6) Check out code from Gerrit head on supermodule and submodule 7) Make submodule change 8) Make supermodule change 9) Push updates 10) Approve submodule updates 11) Approve supermodule updates with the oldest getting approved first What is the expected output? What do you see instead? I expect Gerrit to be able to properly order the supermodule commits against the submodule commits or at least show the 'Missing Blob' error that is in the Gerrit logs as a commit error message. (http://groups.google.com/group/repo-discuss/browse_thread/thread/2d2f31335627a69b?pli=1). Instead, I see my supermodule commits getting stuck in a Submitted, Merge Pending state until I rebase all of them manually. This potentially ends up with having the incorrect submodule at the supermodule HEAD and requires an additional commit to sync everything. Please provide any additional information below.
Mar 2, 2012
#1
phil.hord
Mar 2, 2012
Phil, In this case, the issue is that there are no other collisions except for a hash change on the submodule. I've tried this exact scenario using a Git workflow, and it seems to work just fine (except when it doesn't). And when it doesn't, it just complains that it can't be merged. If Gerrit did this, I'd be perfectly happy. Instead, it sits in a hung state and tells me absolutely nothing about the issue. If you're not passing your submodule commits through Gerrit, how are you ensuring that a checkout of the latest Gerrit head will pick up the proper version of the submodules? I agree that nobody wants to review them but, by reviewing them, I have found mistakes where the HEAD of the submodule was incorrect and needed to be reset for that particular version. Either Gerrit should be "all knowing" about things completely under its control or it should not allow submodules to be pushed. An non-deterministic state that is only evidenced in the logs (not the web interface) is just not useful.
Mar 9, 2012
The reason for the collision is that you are pushing the submodule links for review. If you did not include these in your review-commits, there would be no collision here.
I'm not sure what you mean when you say "And when it doesn't, it just complains that it can't be merged. If Gerrit did this, I'd be perfectly happy." It seems to me that's exactly what Gerrit did. It complained by telling you that the merge was blocked by something. Doesn't Gerrit leave an error note in the commit review notes and send you an email?
Maybe you want Gerrit to tell you right away (on the web page) when there is such a merge collision. I think that's a reasonable thing to do, and I think I've seen Gerrit do this. But I've also seen it show up later, maybe because of pending dependencies at the time of the initial "submit". But I think this is unrelated to submodules. I think it is related to any sort of merge conflict.
> If you're not passing your submodule commits through Gerrit, how are
> you ensuring that a checkout of the latest Gerrit head will pick up
> the proper version of the submodules?
First, we define what "proper version" means. In our case, it means "the already-reviewed and tested same-named-branch commit" on the submodules. So, the superproject 'master' branch is always updated to point to the 'master' commits on the submodules.
During review cycles, we have a Jenkins CI-Server that tests each proposed patchset against all the other submodules' tips for each superproject. If it passes the test (make + unit-test) then Jenkins ticks the 'Verified=+1' box. If it doesn't, 'Verified=-1'.
Finally, after the submodule commit is reviewed and merged ("submit" in Gerrit-speak), our CI-Server runs another sanity check on all the tips, and if it passes again, he pushes a commit on the superproject containing -- updated submodule tips -- to refs/heads/master. The Jenkins CI-Server has a Gerrit user account which allows him to push directly to the branch tip.
It would be nice if Gerrit handled this automatically for us, but he doesn't. Arguably, it's not his job. But it would be convenient if he did.
May 9, 2012
As a side effect of this i encountered an error. Those changes that are hanging in submitted can still be updated with new patch sets. So a suggestion is to lock changes for being updated after submit has been pushed unless they fail to merge but as long as git has not reported this it should no be possible to update the patch set |
|
| ► Sign in to add a comment |