Missing Blob error with submodules.

[GoogleCodeExporter]

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/2d2f31335627a6
9b?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.

Original issue reported on code.google.com by tvaug...@onyxpoint.com on 24 Feb 2012 at 2:58

[GoogleCodeExporter]

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.

Original comment by phil.hord on 2 Mar 2012 at 5:01

[GoogleCodeExporter]

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.

Original comment by tvaug...@onyxpoint.com on 2 Mar 2012 at 5:49

[GoogleCodeExporter]

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.

Original comment by phil.hord on 9 Mar 2012 at 8:09

[GoogleCodeExporter]

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

Original comment by rasmus.v...@switch-gears.dk on 9 May 2012 at 2:40