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

Repo Mirroring Issue #23

Closed
moenasrallah opened this issue Oct 27, 2018 · 2 comments
Closed

Repo Mirroring Issue #23

moenasrallah opened this issue Oct 27, 2018 · 2 comments

Comments

@moenasrallah
Copy link

There seems to be an issue when trying to fork, mirror, or upload your repository on another account (specifically Gitlab). The issue comes from you guys having GIT LFS.
LFS works nicely with your repository, but does not transfer well over anyone that takes your work and wants to amend it.

Refer to the screenshots attached, and the links to others who have the same kind of issues with LFS

image

Also noticed this after doing a git lfs pull... the username area is chopped up

image

git-lfs/git-lfs#1935
git-lfs/git-lfs#911

I know this a unsolved LFS error based from Git's side, but I wanted to give some insight and ask if there might be a solution, workaround, or other methods...

Thank you!

@martins-mozeiko
Copy link
Contributor

martins-mozeiko commented Oct 27, 2018

git lfs mirroring should work correctly between gitlab and github. We use internal gitlab for our primary repository. And we do sync everything to github from time to time.

I believe the error you see is because git lfs by default does not download lfs objects that are not reachable from current commit (for example if lfs file a has been changed multiple times). It downloads only files that are reachable from currently checked out commit. This saves a lot of time because usually you want to just fetch latest source, not whole history of repo, especially for large files like Unity scene or textures, or meshes, etc.

To download all lfs objects run this:

git lfs fetch --all github_remote

Then to upload all lfs objects (not only for those that are currently reachable), run this:

git lfs push --all gitlab_remote

This will create exact mirror of repository, including all the history and all the lfs files.

If something is still missing, please paste the lfs hash here as text, so we can check if we accidentally forgot to push something to github from our repo.

@moenasrallah
Copy link
Author

That did the trick! 🎉
Glad that you have the answers to lfs issues 😄

Support online for lfs problems almost never have any good solutions. ☹️
This was easy and upfront, and I'm sure others will find it useful.

Thank you Martins!

lokesku pushed a commit that referenced this issue Oct 2, 2021
* when rebuilding CubeTown many times in the same workspace I always get segfault like:

  19:06:26  Launched and connected shader compiler UnityShaderCompiler after 0.03 seconds
  19:06:44  Caught fatal signal - signo:11 code:1 errno:0 addr:0xd0000000e
  19:06:44  Obtained 25 stack frames.
  19:06:44  #0  0x007f72a328a3c0 in funlockfile
  19:06:44  #1  0x007f72a3141c5b in memcpy
  19:06:44  #2  0x007f71edcabf64 in vk_optimusGetDeviceProcAddr
  19:06:44  #3  0x0056107c6dad75 in vk::TaskExecutor::HandleCommandStream(GrowableBuffer*, VkCommandBuffer_T*)
  19:06:44  #4  0x0056107c6d9fe6 in vk::TaskExecutor::ExecuteCommandbuffers(vk::CommandBuffer**, int)
  19:06:44  #5  0x0056107c6d6c33 in vk::TaskExecutor::DoFlush(VkFence_T*, VkSemaphore_T*, unsigned long)
  19:06:44  #6  0x0056107c6a3e07 in GfxDeviceVK::SubmitCurrentCommandBuffers(VkSemaphore_T*)
  19:06:44  #7  0x0056107c6a5721 in GfxDeviceVK::FinishRendering()
  19:06:44  #8  0x0056107c61f4dd in GfxDeviceClient::FinishRendering()
  19:06:44  #9  0x0056107bf9b506 in AssetHotreload()
  19:06:44  #10 0x0056107f0fb8ff in AssetHotreload(core::hash_set<UnityGUID, core::hash<UnityGUID>, std::equal_to<UnityGUID> > const&)
  19:06:44  #11 0x0056107f1964e7 in RefreshInternalV2(AssetDatabase::UpdateAssetOptions, ScanFilter const&, InternalRefreshFlagsV2)
  19:06:44  #12 0x0056107f180712 in StopAssetImportingV2(AssetDatabase::UpdateAssetOptions, InternalRefreshFlagsV2, ScanFilter const*)
  19:06:44  #13 0x0056107f180cb1 in RefreshV2(AssetDatabase::UpdateAssetOptions)
  19:06:44  #14 0x0056107f0e5181 in AssetDatabase::Refresh(AssetDatabase::UpdateAssetOptions)
  19:06:44  #15 0x0056107e4fdeb3 in Application::InitializeProject()
  19:06:44  #16 0x0056107f03e606 in InitializeUnity(void*)
  19:06:44  #17 0x007f72a39c3be8 in g_source_get_time
  19:06:44  #18 0x007f72a39c304e in g_main_context_dispatch
  19:06:44  #19 0x007f72a39c3400 in g_main_context_dispatch
  19:06:44  #20 0x007f72a39c36f3 in g_main_loop_run
  19:06:44  #21 0x007f72a405837d in gtk_main
  19:06:44  #22 0x0056107f03dfce in main
  19:06:44  #23 0x007f72a30aa0b3 in __libc_start_main
  19:06:44  #24 0x0056107bd72029 in _start
  19:06:44  /usr/bin/unity-editor: line 11:    11 Segmentation fault      (core dumped) /opt/unity/Editor/Unity "$@"

  when building in workspace with empty "Library" directory and re-running
  it in the same workspace 2nd time (keeping "Library") finishes OK

  Rerun each bundle build upto 3 times before giving up and showing an error.

  Show summary at the end to easily find if some bundles still need to be
  re-triggered or fixed.

* re-try the initial "fetch license" as well as it was sometimes failing
  there already (before starting any bundle build)

* we do something similar in build-simulator.sh already, for "check" function
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants