Gerrit not updating branch after merge

[Doug Luedtke]

I need to discuss this strange event to understand where to go next. I am not sure if this is a Gerrit bug or a Git bug yet, but it caused a branch in Gerrit to not update to the new commit.

Gerrit 2.16.15

Git: 2.19.1.windows.1 and 2.24.1.windows.2

Master: c1--c2--c3

Branch1: c1--c2--c3--c4--c5--c6--c7

1. The user merged Branch1 into Master locally, and Git showed about 100 lines of creates/deletes/renames, but then git status shows "nothing to commit, working tree clean."

2. So they decided to use "git commit --allow-empty" and then push that to Gerrit for review.

3. The code review showed the parent as Branch1 only and a commit message describing the merge.

4. User self approves the votes and submits.

5. Gerrit shows status as merged. Gerrit auto added the comment: "Marking change merged without cherry-picking to branch, as the resulting commit would be empty."

The git history doesn't seem to reflect any changes when cloning again. Git Log shows the same commits from before the merge for each branch. There is no error in the error_log. I am unable to reach the commit listed in the code review after cloning. I am able to reach the commit if I clone directly from Gerrit's file system. It seems to be an orphan commit.

I was able to reproduce this situation with two other branches in a test environment.

This doesn't seem like expected behavior to me for Git and Gerrit. What do you think? Why did Git behave like that with the merge? Why does Gerrit not offer the most recent commit?

And while troubleshooting, the merge can be done locally again because Gerrit is not advertising the merge commit. When locally merging Branch1 into Master, Git will now say that I am 4 commits ahead of origin/Master, but it still says "nothing to commit, working tree clean."

[Doug Luedtke]

Am I wrong to expect this behavior to be different?

[David Pursehouse]

On Sat, 7 Mar 2020, 08:10 Doug Luedtke, <douglas...@gmail.com> wrote:

I need to discuss this strange event to understand where to go next. I am not sure if this is a Gerrit bug or a Git bug yet, but it caused a branch in Gerrit to not update to the new commit.

Gerrit 2.16.15

Git: 2.19.1.windows.1 and 2.24.1.windows.2

Master: c1--c2--c3

Branch1: c1--c2--c3--c4--c5--c6--c7

1. The user merged Branch1 into Master locally,

In this situation it's a fast-forward from c3 to c7 so there is no merge commit created. 

If you want to get the contents of branch1 into master you will need to either push it directly, or create an explicit merge commit by using the --no-ff option on the git merge command. 

and Git showed about 100 lines of creates/deletes/renames, but then git status shows "nothing to commit, working tree clean."

2. So they decided to use "git commit --allow-empty" and then push that to Gerrit for review.

3. The code review showed the parent as Branch1 only and a commit message describing the merge.

4. User self approves the votes and submits.

5. Gerrit shows status as merged. Gerrit auto added the comment: "Marking change merged without cherry-picking to branch, as the resulting commit would be empty."

The git history doesn't seem to reflect any changes when cloning again. Git Log shows the same commits from before the merge for each branch. There is no error in the error_log. I am unable to reach the commit listed in the code review after cloning. I am able to reach the commit if I clone directly from Gerrit's file system. It seems to be an orphan commit.

I was able to reproduce this situation with two other branches in a test environment.

This doesn't seem like expected behavior to me for Git and Gerrit. What do you think? Why did Git behave like that with the merge? Why does Gerrit not offer the most recent commit?

And while troubleshooting, the merge can be done locally again because Gerrit is not advertising the merge commit. When locally merging Branch1 into Master, Git will now say that I am 4 commits ahead of origin/Master, but it still says "nothing to commit, working tree clean."

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/d18d8846-8de3-44bd-a721-b4d8b361add8%40googlegroups.com.

[Doug Luedtke]

On Monday, March 9, 2020 at 9:10:52 AM UTC-5, David Pursehouse wrote:

On Sat, 7 Mar 2020, 08:10 Doug Luedtke, <douglas...@gmail.com> wrote:

I need to discuss this strange event to understand where to go next. I am not sure if this is a Gerrit bug or a Git bug yet, but it caused a branch in Gerrit to not update to the new commit.

Gerrit 2.16.15

Git: 2.19.1.windows.1 and 2.24.1.windows.2

Master: c1--c2--c3

Branch1: c1--c2--c3--c4--c5--c6--c7

1. The user merged Branch1 into Master locally,

In this situation it's a fast-forward from c3 to c7 so there is no merge commit created. 

If you want to get the contents of branch1 into master you will need to either push it directly, or create an explicit merge commit by using the --no-ff option on the git merge command. 

Ok, thank you for that information. Then I was not understanding how it should have looked on the client side. 

The problem is Gerrit did not update the pointer for master. I did find an error in the logs after searching some more.

[2020-03-06 10:28:22,343] [ReceiveCommits-109] WARN  com.google.gerrit.server.git.receive.ReceiveCommits : Skipping change updates on something/something/something/something-something because ref update failed: REJECTED_OTHER_REASON no new changes [CONTEXT RECEIVE_ID="something/something/something/something-something-15XXXXXXXXXXXXXX35-5bXXXXX29" ]

And because the user did --allow-empty and submitted it, the pointer never changed (still shows as c3). The submitted code review shows it should be a sha1 that is only available from the Gerrit file system, not by fetching. I don't want to revert the change as I'm afraid it will cause a future merge to not include those commits.

[Doug Luedtke]

I went ahead and did the git merge --no-ff branch/name and pushed that for review. The user said it looked as expected and submitted it. The pointer for master has not changed. It still shows as "c3" in my example in the first post.

Master: c1--c2--c3

Branch1: c1--c2--c3--c4--c5--c6--c7

CodeReview1 merge Branch1 to master with commit --allow-empty: c8 (Gerrit not showing it in the branch history, not advertised to fetch from Gerrit. Shows only Branch1 as parent in codereview)

CodeReview2 merge Branch1 to master with --no-ff: c9 (Gerrit not showing it in the branch history, not advertised to fetch from Gerrit. Does show two parents in the codereview)

What would be recommended to fix this?

• I shouldn't revert the merge, as I would expect that to keep those commits from being merged in later.
• I'm not sure what to do with the (now two) problem commits that can only be reached at the server file system, but not the Gerrit app.
• I can delete the master branch and recreate it at the sha1 point I think it should be. Requires abandoning about a dozen open changes.
• I can force push what I think should be there.

[Matthias Sohn]

I'd create a commit with a dummy change on branch1 e.g. change some comment and then merge it again

to master using the --no-ff option to ensure this time you get a change to review and submit.

-Matthias

[Doug Luedtke]

Thank you, Matthias and David.

Nevermind the issue in my last comment. The --no-ff worked as expected. I looked too quickly at the status, it wasn't submitted yet. Now the master branch is updated as expected.

I hope everyone enjoyed their Monday entertainment. I'm here all week. Don't forget to tip your Admins and Devs.