Broken migration from gitlab #462

Open
opened 3 weeks ago by dyfet · 6 comments
dyfet commented 3 weeks ago

Git migration from https://gitlab.com/tychosoft/produceit to
https://codeberg.org/dyfet/broken-produceit using gitlab migration, with access token, and "merge requests" selected...

The git repo itself is broken...

git clone git@codeberg.org:dyfet/broken-produceit
Cloning into 'broken-produceit'...
error: refs/pull/12/head does not point to a valid object!
error: refs/pull/15/head does not point to a valid object!
remote: Enumerating objects: 1214, done.
remote: Counting objects: 100% (1214/1214), done.
remote: Compressing objects: 100% (369/369), done.
remote: Total 1214 (delta 823), reused 1210 (delta 821), pack-reused 0
Receiving objects: 100% (1214/1214), 256.93 KiB | 722.00 KiB/s, done.
Resolving deltas: 100% (823/823), done.

And creating a new merge request produces a 500 (internal server) error.

Seems related to upstream:

https://github.com/go-gitea/gitea/issues/15155

may even be the same, since that also talks about the refs being broken, though not from entirely the same perspective. If so, it looks like it is in progress and may be hard to fix.

Git migration from https://gitlab.com/tychosoft/produceit to https://codeberg.org/dyfet/broken-produceit using gitlab migration, with access token, and "merge requests" selected... The git repo itself is broken... git clone git@codeberg.org:dyfet/broken-produceit Cloning into 'broken-produceit'... error: refs/pull/12/head does not point to a valid object! error: refs/pull/15/head does not point to a valid object! remote: Enumerating objects: 1214, done. remote: Counting objects: 100% (1214/1214), done. remote: Compressing objects: 100% (369/369), done. remote: Total 1214 (delta 823), reused 1210 (delta 821), pack-reused 0 Receiving objects: 100% (1214/1214), 256.93 KiB | 722.00 KiB/s, done. Resolving deltas: 100% (823/823), done. And creating a new merge request produces a 500 (internal server) error. Seems related to upstream: https://github.com/go-gitea/gitea/issues/15155 may even be the same, since that also talks about the refs being broken, though not from entirely the same perspective. If so, it looks like it is in progress and may be hard to fix. <!-- NOTE: If your issue is a security concern, please send an email to contact@codeberg.org (and if related to Gitea also to security@gitea.io) instead of opening a public issue. Thank you. Welcome to the Codeberg Community Tracker. This is the right place for bug reports, feature requests and feedback. It's the central place where we track progress and discuss, so please open issues here unless you are sure it's directly related to a specific Codeberg product and only some contributors there need to join the discussion. Easy rule: If you are unsure, report it here. When reporting bugs or asking for features in the software itself, please understand that Codeberg is a fork of Gitea. Please always check upstream (→ see FAQ) if your there is already an open issue. If not, you'd really help us if you could directly get in touch with the maintainers and open an issue here if you think a wider audience should know about that (e. g. when discussing hotfixes, backports or when discussing whether some feature should become part of Gitea or a Codeberg "add-on"). If you don't have a GitHub account, please mention this and we'll gladly forward your report to the Gitea maintainers. Thank you for reporting your findings and giving feedback on Codeberg. ## Some FAQ: ### What does upstream mean? Upstream refers to Gitea, the software Codeberg is built upon. If we ask you if you can report upstream, please visit https://github.com/go-gitea/gitea/issues and check for the bug there and report elsewise. It's usually good if the person interested in a feature or bugfix opens the request to react to questions and join the discussion. We would usually just fire the report, but won't find the time to properly react to that ... **If you do not have a GitHub account**, just tell us and we'll happily forward the report for you. ### I just noticed a typo in the sign_up / sing_up route when regis... No, this is not a typo, but intentional. It was a quick fix to avoid spammers targetting our instance and it actually worked out quite well to rename the route from sign_up to sing_up (few people notice, nice to see you have sharp eyes) ... we might have to take more effective countermeasures in the future, but for now we're actually quite good with that one ... ### How can I help? If you want to help improving Codeberg as a community home for software development, we'll gladly welcome your contribution. Check out the docs about improving Codeberg https://docs.codeberg.org/improving-codeberg/ and have a look at the open issues, especially those that are looking for contribution https://codeberg.org/Codeberg/Community/issues?state=open&labels=105 - some of them don't even require much coding knowledge. We are also happy if you forward bug reports to Gitea if the original author hasn't done that yet or hasn't got a GitHub account. -->
Collaborator

I'm wondering - your source project on GitLab hasn't got any public Merge Requests and also not the branches? Or are they present somehow?

I'm wondering - your source project on GitLab hasn't got any public Merge Requests and also not the branches? Or are they present somehow?
fnetX added the
bug
gitea-related
labels 3 weeks ago
Poster

I'm wondering - your source project on GitLab hasn't got any public Merge Requests and also not the branches? Or are they present somehow?

I don't have any open ones, but merged should have been visible. Though maybe it was only visible to project members? In any case, on gitlab, I do squash merges and auto-delete the source branch. Maybe it is also related to that workflow?

> I'm wondering - your source project on GitLab hasn't got any public Merge Requests and also not the branches? Or are they present somehow? I don't have any open ones, but merged should have been visible. Though maybe it was only visible to project members? In any case, on gitlab, I do squash merges and auto-delete the source branch. Maybe it is also related to that workflow?
Poster

@fnetX so I played with permissions, signed out of gitlab, and then made sure I could see merged requests made as an external viewer...

https://gitlab.com/tychosoft/produceit/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged

@fnetX so I played with permissions, signed out of gitlab, and then made sure I could see merged requests made as an external viewer... https://gitlab.com/tychosoft/produceit/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged
Collaborator

I'll have a look

I'll have a look
6543 self-assigned this 3 weeks ago
fnetX added the
upstream
label 3 weeks ago
Collaborator

I kind a have an idear what went wrong ... it's a generall issue, if git clone does not migrate needed commits, merged pulls do reference too

I kind a have an idear what went wrong ... it's a generall issue, if `git clone` does not migrate needed commits, merged pulls do reference too
Poster

I kind a have an idear what went wrong ... it's a generall issue, if git clone does not migrate needed commits, merged pulls do reference too

So they are probably commits not/no longer attached to any branch or tag? If so I guess probably the PR should be dropped in migration too when that happens.

> I kind a have an idear what went wrong ... it's a generall issue, if `git clone` does not migrate needed commits, merged pulls do reference too So they are probably commits not/no longer attached to any branch or tag? If so I guess probably the PR should be dropped in migration too when that happens.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.