Would adding a symbolic-ref to the bare repo on the gerrit server cause issues?

[Eric Isakson]

I'm investigating using a symbolic-ref on the server side to help our teams transition from using master to using main as the default branch. The idea is to:

• create a main branch based on the commit master is currently pointing to
• set the HEAD to refs/heads/main
• create a symbolic-ref in the bare repo on the server using: git symbolic-ref refs/heads/master refs/heads/main
• give folks time to transition all their tools and processes that currently operate on master to start using main
• eventually delete the symbolic-ref

So for a while from a git client perspective, master still exists, looks and smells like a branch but main and master on the remote stay in sync.

I'm curious if adding a symbolic-ref in the bare repo like this would cause issues with gerrit's data and processes or if this is already supported. Any issues I should be on the lookout for? There may be active changesets in flight against master when I do this, would those be negatively impacted?

Thanks for any feedback on this!

[Doug Luedtke]

Great question. This is something we are interested in also. 

[Matthias Sohn]

Did you try with a test repo ?

 

Thanks for any feedback on this!

--
--
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/CAFsc5yorgs-DTaQ_T0OE6ntfQQvd3FirtOJ0LOh-sE%3DsaFzNXw%40mail.gmail.com.

[Eric Isakson]

Did some really basic exploration, created a repo with a master branch, pushed a couple of changesets to represent work that is in flight, added a main branch, reset the head and added the symbolic ref.

When I tried to submit the changeset, got a dialog in the UI with:

An error occurred

Cannot perform action: Lock failure

* Updating a ref failed with LOCK_FAILURE.

This may be a temporary issue due to concurrent updates.

Please retry later.

and this plus some deep stack traces in the logs:

[2021-01-08T20:09:17.831Z] [HTTP POST /changes/symbolic-ref-experiment~1/revisions/1/submit (erisak from 10.25.16.106)] INFO  com.googlesource.gerrit.plugins.hooks.HookFactory : hooks.submitHook resolved to /var/gerrit/hooks/submit [CONTEXT SUBMISSION_ID="1-1610136557812-f42bed60" project="symbolic-ref-experiment" ]
[2021-01-08T20:09:41.596Z] [HTTP POST /changes/symbolic-ref-experiment~1/revisions/1/submit (erisak from 10.25.16.106)] ERROR com.google.gerrit.httpd.restapi.RestApiServlet : Error in POST /changes/symbolic-ref-experiment~1/revisions/1/submit [CONTEXT project="symbolic-ref-experiment" ]
com.google.gerrit.server.update.UpdateException: com.google.gerrit.git.LockFailureException: Update aborted with one or more lock failures: PackedBatchRefUpdate[
  UPDATE: 393e28084626acf6671ed63d45cc96dbb9d09d8e 7d5ddc6eff3759363d82a9ddd57aaebe545ba7ab refs/heads/master  (LOCK_FAILURE)
  UPDATE: aba8419078a1f04a060f1f8b41c0291b853fcf41 3ddb6aa4bd3db28b2a04e846017c3340c53f8f06 refs/changes/01/1/meta  (REJECTED_OTHER_REASON: transaction aborted)
]
        at com.google.gerrit.server.update.BatchUpdate.wrapAndThrowException(BatchUpdate.java:229)

However it was easy to resolve this by opening the changeset in the UI and selecting the "Move change" from the context menu and selecting the main branch as the target. The submit then worked and on my client side both master and main appear like normal branches and both of them update to the new commit on the pull.

We also use replication features but don't have that turned on for this initial experimentation. I'm hoping that someone close to the gerrit code can indicate whether what I'm doing would be likely to break anything. Since it is definitely behind the curtain to be running git commands in that bare repo.