Issue 1271: Missing Blob error with submodules.
Status:  New
Owner: ----
Reported by tvaug...@onyxpoint.com, Feb 24, 2012
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
Automatically merging superproject branches with differing submodule links is something git cannot do.  I can't imagine a deterministic way to handle this intelligently.  I don't see a clear definition of "properly order" in your description.

In our workflow, we never push gitlink changes (superproject's references to submodules) to Gerrit for review.  No one wants to review those visually, and Gerrit doesn't handle them well otherwise.  Maybe your project is not amenable to this workflow, however.
Mar 2, 2012
#2 tvaug...@onyxpoint.com
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
#3 phil.hord
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
#4 rasmus.v...@switch-gears.dk
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