Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[migration-tools] Pull all branches prior to changing remote #36597

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

cottsay
Copy link
Member

@cottsay cottsay commented Mar 24, 2023

There are two reasons this is probably the right thing to do:

  1. When the remote gets modified, it breaks Blooms mechanism for determining when a branch already exists remotely prior to creating a new one, which has previously resulted in obliterating the release and patch branches during same-distro migrations.
  2. When the repository is moved from one location to another, we end up mirroring all the tags from the original location but only mirroring the branches from the source and destination distros, which is weird. This way we'll mirror everything.

Marking as draft until I can test that this doesn't regress migration to a different distro.

Fixes #32128

@nuclearsandwich
Copy link
Member

Another possibility here is to implement the full mirror clone and push that I have been doing for pre-emptive ros2-gbp repo creation. I think the net effect would be the same but it might be easier to audit.

Because of the way git's data model and work trees interact we cannot use --mirror or an equivalent refspec with git-fetch origin +refs/*:refs/* with a clone containing a worktree. So we'd either need to create a mirror clone initially and then manually create a worktree (which bloom's git handling may not be able to deal with) or manually fetch, checkout, and push all refs. Which the track_branches from bloom may be doing for us.

@nuclearsandwich
Copy link
Member

@cottsay should we use the last of our shift on Monday to either polish this off and merge it or close it out?

@github-actions
Copy link

This PR hasn't been activity in 14 days. If you are still are interested in getting it merged please provide an update. Otherwise it will likely be closed by a rosdistro maintainer following our contributing policy. It's been labeled "stale" for visibility to the maintainers. If this label isn't appropriate, you can ask a maintainer to remove the label and add the 'persistent' label.

@github-actions github-actions bot added the stale Issue/PR hasn't been active in a while and may be closed. label Jul 14, 2023
@cottsay cottsay removed the stale Issue/PR hasn't been active in a while and may be closed. label Jul 14, 2023
@github-actions
Copy link

This PR hasn't been activity in 14 days. If you are still are interested in getting it merged please provide an update. Otherwise it will likely be closed by a rosdistro maintainer following our contributing policy. It's been labeled "stale" for visibility to the maintainers. If this label isn't appropriate, you can ask a maintainer to remove the label and add the 'persistent' label.

@github-actions github-actions bot added the stale Issue/PR hasn't been active in a while and may be closed. label Jul 29, 2023
@mjcarroll
Copy link
Member

@cottsay and @nuclearsandwich any updates on this one?

@github-actions github-actions bot removed the stale Issue/PR hasn't been active in a while and may be closed. label Aug 30, 2023
@cottsay cottsay added the persistent Issue/PR won't be marked as stale if inactive for a while. label Sep 11, 2023
@mjcarroll
Copy link
Member

@cottsay and @nuclearsandwich any updates on this one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
persistent Issue/PR won't be marked as stale if inactive for a while.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[migration-tools] release and platform branch history is not preserved when source and dest are the same.
3 participants