| Issue 779: | New merged commit not immediately available through Git | |
| 2 people starred this issue and may be notified of changes. | Back to list |
Affected Version: 2.1.5 What steps will reproduce the problem? 1. Submit a reviewed change. 2. Query the change (using "gerrit query --current-patch-set --format JSON -- project:... branch:... status:merged") that shows it as merged. 3. "git fetch" the repository 4. Try to access the newly merged commit (ex. git cat-file) What is the expected output? What do you see instead? The fetch since it is after a "gerrit query" that shows the commit as merged should have picked it up but it doesn't and the "git cat-file" errors. Please provide any additional information below. I'm not experiencing this often, once in a while in the application I have built around "gerrit query"/"git fetch" however I think this is a bug that should be fixed (if Gerrit for whatever reason takes time to make all the updates necessary for a submitted change then it should not advertise it as "merged"). Now I need to implement some workaround for this issue to not expect that the current patch set commit of a merged change exists in a repository that has been fetched after the query. Another solution I'm considering is fetching "refs/changes/*" contents by default in that repository.
Nov 18, 2010
Project Member
#1
bklarson@gmail.com
Nov 18, 2010
Yeah that does look related (not familiar with the Gerrit code tho, the code paths may be different).
May 19, 2011
@dizzy, are you fetching directly from the Gerrit server or a mirror?
May 19, 2011
Directly from the Gerrit server (from its builtin SSHD).
May 19, 2011
Ok, then probably the same as Issue 755 . We (Gerrit devs) should look into this more.
Blockedon:
755
May 19, 2011
Yeah, #755 seems related.
May 20, 2011
Issue 755 was about ReceiveCommits sending notification of a new patch set by stream events before it had finished updating the Git repository. The notification call was made a bit too early. I have moved it after the Git update, where it should have been. I don't (yet) understand how this issue occurs. The original report describes a change showing up in a query with status:merged, but the commit is not in the destination branch. From what I can tell of MergeOp, this is impossible. The Git branch is updated with the merged commit before the database is updated. What submit policy is the project using?
May 20, 2011
If the project is using cherry-pick submit policy, this is a duplicate of issue 871 .
May 20, 2011
The project is using FAST_FORWARD_ONLY Notice the Gerrit version when I reported the issue, was the code you're looking at changed since 2.1.5?
May 20, 2011
No, I looked at the changes between 2.1.5 and current tip and did not see anything that might change the behavior related to this change.
May 20, 2011
I have since modified that code to fail graciously when it hits that problem so I can't say if it still happens. Thanks for looking into this, it makes sense to close it as not repeatable.
May 20, 2011
(No comment was entered for this change.)
Status:
CannotReproduce
|
|
| ► Sign in to add a comment |