0

In the initial commit of the project I am working on, there are files that were added in the initial commit, and then completely scrapped in the next commit. These files are bigger than 128 mb therefore I cannot push these files to GH.

The intent was to migrate the project to GH from GL and these files that were put there do not allow for GH to accommodate them.

I am using a visual representation for the branches. After trying This answer I have realized that git basically kept the origin/main and "beheaded" the Local branch from the initial commit and created a parallel version. I assume, locally. Initial commit

Yes, whoever (and I swear it was not me) has screwed up initial commit -> scrapped the whole thing with another initial commit and replaced it again with the third initial commit, this time adding the right files. (grey dots)

Let me explain the colors:

  • Orange : this is Local branch which is now 551/552 push pulls away :) . And yes, it is detached from initial commit.
  • Red : Still the origin/main. Still starts with initial commit that I want to get rid of
  • Green and Blue : dev branches that are now locally and origin/dev respectively. As you can guess they also follow each other in parallel

Question: Is there a way I can push/save/ to my local machine and then push it to GH without touching the origin/main and origin/dev since they are attached to initial commit 0 and the local branch does not ? Or should I somehow replace the whole branch history in GL with my local history ?

Thank you in advance

RomanSmoll
  • 81
  • 11
  • It's not clear how GL comes into play here. Why not make your local repo look like how you want it and then push that repo to GH? I'm thinking you can Just delete the branches that reference the bad commits, leaving you with the good orange/green branches locally. Then push that repo to GH... – TTT Aug 24 '22 at 15:53
  • @TTT , If I would try to migrate the project from GL to GH from within GJ, it asks for GL credentials for temp connection. If I try to save the whole repository using ```git lfs fetch --all && git push mirror ``` it would save the GL data, which has not changed. How do I save that "beheaded, local " tree of the project completely bypassing GL then ? – RomanSmoll Aug 24 '22 at 16:00
  • Oh I see. You literally meant you are migrating a repo from GL directly to GH. I'm not sure what the advantages of doing that are, compared to just pushing a repo from your local machine to GH. If you want to do it from GL directly, you need to force push your fixed up branches to GL first, which will make the old commits unreachable. Then any new clones, and I assume the migration too, will not include those commits. – TTT Aug 24 '22 at 16:03
  • @TTT, [link](https://github.com/orgs/community/discussions/21646) this is what i found as a response to migration. GH has its own process that allows to copy the whole branches history etc. As I mentioned, it is obsolete once you have big files, and sadly for me , the initial commit has one.. So -> getting rid of initial commit 0. I think I have the whole GL project tree in my local machine somewhere, beautiful and beheaded. I just need to know how can I find it , and how to upload the whole local tree to GH manually – RomanSmoll Aug 24 '22 at 16:11
  • @TTT Wait , i might have misread your message. Are you saying that if I force push my local beheaded branch to GL right now, it will overwrite the one stored there? because it clearly tells me that my branch is 551 push pulls apart (which is exactly how many commits are there from initial/local/beheaded to initial git to get rid off.... – RomanSmoll Aug 24 '22 at 16:33
  • Yes, kind of. The old commits will still be there on GL, but unreachable except by commit ID. Depending on your GL server settings those old commits may get garbage collected after some amount of time. Note any tags/branches pointing to the old version of the commits somewhere in the repo may stick around and force those old commits to be reachable. You can try the force push, and then re-clone the repo to another directory to confirm the repo size is smaller and those old commits do not exist in the new clone. BUT- before force pushing make sure everyone using the repo knows what's happening. – TTT Aug 24 '22 at 16:39
  • @TTT I dont think push force is a solution. as it will keel the git remote which i intent to replace with the local branch.. I have done this [https://stackoverflow.com/a/51535883/15382162](action) on one of my other projects..that thing completely detached dev branch from master and then I had to do the rebase...and then the original/main disappeared...maybe rebase should be a better solution ? – RomanSmoll Aug 28 '22 at 13:42
  • Sorry I don't understand your last comment. Maybe you know this already, but it may help clear up some things in case you don't: branches are simply pointers to a 40 character (hash) commit ID, and we use branches because it's easier for humans to remember them. When you "push" a branch, you are simply changing what commit ID the remote branch points to, so that it matches the commit ID your local branch points to. If the remote branch is pointing to a commit ID that is not "reachable" by the commit ID you are trying to change it to, then you must force push instead. – TTT Aug 28 '22 at 16:40
  • Anytime you have already pushed a branch, and then you rebase that branch, or amend a commit, or even reset backwards, and then try to push again, you'll need to force push. The previous commit IDs are not destroyed when you force push, even if nothing is pointing to them anymore (other branches or tags). Those commits hang around until they are garbage collected. – TTT Aug 28 '22 at 16:42

0 Answers0