Re: How do I find out what is holding up a string of merges?

I just verified that this same issue exists in 2.3-rc0.

Thanks,

Trevor

On Thu, Feb 23, 2012 at 3:52 PM, Trevor Vaughan <[EMAIL PROTECTED]> wrote:
> Sorry to keep beating on this but I did some more digging and finally
> ignored the web interface and dug around in the logs and found an
> exact replica of this situation:
> http://groups.google.com/group/repo-discuss/browse_thread/thread/2d2f31335627a69b
>
> I cant seem to find any reference of this being fixed anywhere though
> there are several references to bug #390 which shouldn't be an issue
> in 2.2.2.1 unless a regression has cropped up.
>
> Thanks,
>
> Trevor
>
> On Thu, Feb 23, 2012 at 2:58 PM, Trevor Vaughan <[EMAIL PROTECTED]> wrote:
>> Ok, I've got some more data on this.
>>
>> I just tested this with the following scenario:
>>
>> 1) Rewind to Gerrit head
>> 2) Make submodule update
>> 3) Push submodule update
>> 4) Make supermodule update
>> 5) Push supermodule update
>> 6) Rewind to Gerrit head on supermodule and submodule
>> 7) Make submodule update
>> 8) Make supermodule update
>> 9) Push updates
>> 10) Approve submodule updates
>> 11) Approve supermodule updates with the oldest getting approved first
>>
>> Now I *think* I know why this is a problem, but I'm not quite sure.
>>
>> However, Gerrit doesn't give me any clue as to what is wrong. It just
>> has the later supermodule commit sitting in a Pending state. No error
>> message, no e-mail, no nothing. This sits that way until I rework my
>> history to get them in the correct order and then resubmit.
>>
>> I'm assuming that this is something that Gerrit *should* catch and warn 
>> about.
>>
>> Thanks,
>>
>> Trevor
>>
>> On Wed, Feb 22, 2012 at 5:36 PM, Trevor Vaughan <[EMAIL PROTECTED]> wrote:
>>> So, what seems to be happening is that my submodule merge is failing,
>>> but Gerrit isn't reporting on this.
>>>
>>> I'm now performing the submodule merges by hand and getting something
>>> like the following:
>>>
>>> git checkout <long random string of stuff> FETCH_HEAD
>>> git rebase gerrit/master
>>>
>>> And I get:
>>>
>>> Failed to merge submodule foo (not fast-forward)
>>> ...
>>> git update-index --cacheinfo <hash, etc...> "/path/to/foo"
>>>
>>> which will accept this suggestion.
>>>
>>> When I do this and update the offending commit, everything merges just fine.
>>>
>>> My question now is, why isn't Gerrit reporting this failure?
>>>
>>> Thanks,
>>>
>>> Trevor
>>>
>>> On Wed, Feb 22, 2012 at 5:12 PM, Matthias Sohn
>>> <[EMAIL PROTECTED]> wrote:
>>>> check the reflog on the server, if somebody rewrote or reset some branch
>>>> the reflog should know about that
>>>>
>>>> --
>>>> Matthias
>>>>
>>>> 2012/2/22 Trevor Vaughan <[EMAIL PROTECTED]>
>>>>>
>>>>> Ok, I verified that it's not #1, now I have the sinking feeling that
>>>>> it might be #2.
>>>>>
>>>>> Is there a sane way of untangling that web of madness?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Trevor
>>>>>
>>>>> On Wed, Feb 22, 2012 at 4:25 PM, Edwin Kempin <[EMAIL PROTECTED]>
>>>>> wrote:
>>>>> > Yes, here two more explanations for this situation:
>>>>> >
>>>>> > 1. The commit was actually merged into the central branch, but the
>>>>> > change
>>>>> > state was not updated. This can happen when pushing a tag that points to
>>>>> > commit of an open change. See issue 600 [1] for details. If this is the
>>>>> > case
>>>>> > you have to update the change state in the database as described in this
>>>>> > issue.
>>>>> >
>>>>> > 2. Somebody was resetting the central branch. Imagine your central
>>>>> > branch
>>>>> > points to A and you upload a change B that is based on A and then
>>>>> > another
>>>>> > change C that is based on B. Now B gets submitted and merged and the
>>>>> > central
>>>>> > branch points to B. If now the central branch is reset to A you have the
>>>>> > situation that change B is in state MERGED and C which depends on it
>>>>> > gets
>>>>> > stuck in state SUBMITTED, MERGE PENDING when it is submitted. This is
>>>>> > correct because B (on which C depends) is missing in the destination
>>>>> > branch.
>>>>> >
>>>>> > [1] http://code.google.com/p/gerrit/issues/detail?id=600
>>>>> >
>>>>> > 2012/2/22 Trevor Vaughan <[EMAIL PROTECTED]>
>>>>> >>
>>>>> >> So, I just re-verified the list and we don't have anything that shows
>>>>> >> dependencies on items that have been abandoned at this point.
>>>>> >>
>>>>> >> Also, everything that is hanging is dependent on something stated as
>>>>> >> MERGED and there are no comments from Gerrit stating that the change
>>>>> >> could not be merged.
>>>>> >>
>>>>> >> Any other ideas?
>>>>> >>
>>>>> >> Thanks,
>>>>> >>
>>>>> >> Trevor
>>>>> >>
>>>>> >> On Wed, Feb 22, 2012 at 3:52 PM, Trevor Vaughan
>>>>> >> <[EMAIL PROTECTED]>
>>>>> >> wrote:
>>>>> >> > Ah, I hadn't realized that about changes that depend on abandoned
>>>>> >> > changes.
>>>>> >> >
>>>>> >> > Perhaps this is the issue.
>>>>> >> >
>>>>> >> > Thanks,
>>>>> >> >
>>>>> >> > Trevor
>>>>> >> >
>>>>> >> > On Wed, Feb 22, 2012 at 3:43 PM, Matthias Sohn
>>>>> >> > <[EMAIL PROTECTED]> wrote:
>>>>> >> >> 2012/2/22 Trevor Vaughan <[EMAIL PROTECTED]>
>>>>> >> >>>
>>>>> >> >>> So, I've now got a good half dozen items sitting in SUBMITTED state
>>>>> >> >>> on
>>>>> >> >>> my Gerrit queue but none of them are merging and the dependencies
>>>>> >> >>> all
>>>>> >> >>> show to be in either MERGED or ABANDONED state.
>>>>> >> >>>
>>>>> >> >>> How do I tell what's holding things up?
>>>>> >> >>>
>>>>> >> >>> I am using submodules but I don't know if that has anything to do
>>>>> >> >>> with
>>>>> >> >>> it.
>>>>> >> >>>
>>>>> >> >>> Gerrit -> 2.2.2.1
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> Changes which only depend on merged dependencies should be
>>>>> >> >> submittable, except if they conflict with other changes merged
>>>>> >> >> earlier. Then you should see a review comment from Gerrit stating
>>>>> >> >> that there is a conflict which needs to be resolved.
>>>>> >> >>
>>>>> >> >> Changes which depend on abandoned changes need to be
>>>>> >> >> rebased, usually onto origin/master.
>>>>> >> >>
>>>>> >> >> --
>>>>> >> >> Matthias
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > --
>>>>> >> > Trevor Vaughan
>>>>> >> > Vice President, Onyx Point, Inc
>>>>> >> > (410) 541-6699
>>>>> >> > [EMAIL PROTECTED]
>>>>> >> >
>>>>> >> > -- This account not approved for unencrypted proprietary information
>>>>> >> > --
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Trevor Vaughan
>>>>> >> Vice President, Onyx Point, Inc
>>>>> >> (410) 541-6699
>>>>> >> [EMAIL PROTECTED]
>>>>> >>
>>>>> >> -- This account not approved for unencrypted proprietary information --
>>>>> >>
>>>>> >> --
>>>>> >> To unsubscribe, email [EMAIL PROTECTED]
>>>>> >> More info at http://groups.google.com/group/repo-discuss?hl=en
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Trevor Vaughan
>>>>> Vice President, Onyx Point, Inc
>>>>> (410) 541-6699
>>>>> [EMAIL PROTECTED]
>>>>>
>>>>> -- This account not approved for unencrypted proprietary information --
>>>>>
>>>>> --
>>>>> To unsubscribe, email [EMAIL PROTECTED]
>>>>> More info at http://groups.google.com/group/repo-discuss?hl=en
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias
>>>
>>>
>>>
>>> --
>>> Trevor Vaughan
>>> Vice President, Onyx Point, Inc
>>> (410) 541-6699
>>> [EMAIL PROTECTED]
>>>
>>> -- This account not approved for unencrypted proprietary information --
>>
>>
>>
>> --
>> Trevor Vaughan
>> Vice President, Onyx Point, Inc
>> (410) 541-6699
>> [EMAIL PROTECTED]
>>
>> -- This account not approved for unencrypted proprietary information --
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
> [EMAIL PROTECTED]
>
> -- This account not approved for unencrypted proprietary information --



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
[EMAIL PROTECTED]

-- This account not approved for unencrypted proprietary information --

-- 
To unsubscribe, email [EMAIL PROTECTED]
More info at http://groups.google.com/group/repo-discuss?hl=en