CODEWITHSUNDEEP
reactjsgitgithub
mazorSharp
mazorSharp

Reputation: 33

Not able to push to new repository on Github

I created a repository on GitHub and pushed successfully to it. However, I had trouble pushing my 'backend' folder. Eventually I did get but it still didn't look the same as the code I had on VS Code. For sake of organization I decided to delete that repository and create a new one. This time the folders I was missing previously (two parents folders, one for frontend, one for backend) managed to upload but all the files inside them (that were pushed to previously deleted repository) didn't get pushed to my new repository.

Git add -A and git add . don't change anything. git push, returns 'Everything up-to-date'. git remote is connected just fine.

Please help stack overflow community, you're my only hope. current repository if it helps: https://github.com/mazorSharp/mern-e-commerce

Upvotes: 1

Views: 551

Answers (2)

kamprasad
kamprasad

Reputation: 648

Probably you need to delete .git folder by using the following command and start with git init and point to the new repository. Note: This will remove your all previous commits.

rm -rf .git

Or else you can change the upstream URL by using this command,

git remote set-url origin <<new git url>>

Upvotes: 0

torek
torek

Reputation: 488463

Your backend and frontend entries in the listed repository are both gitlinks: the main operating part of a submodule. You get a submodule because you told Git to store a Git repository inside a Git repository. Git literally cannot store a Git repository inside a Git repository, so it won't. Instead, Git adds what I like to call a "half-assed submodule": the part that says use this particular commit: ______ (insert hash ID here) from the associated Git repository.

The reason this is "half-assed" is that the "associated" Git repository isn't associated. To be associated, Git needs a separate piece of information. To put that information into Git—which you need only do once per submodule—you would normally use git submodule add. This will create or update the .gitmodules file, in which the association information is stored. Once you have both pieces of information, the gitlink becomes useful ("fully assed"?).

Once you have a proper submodule, cloning the superproject gets you a repository that refers to some other repository. That other repository is not yet cloned so you must run git submodule update --init or equivalent. This tells your Git software to poke around in the submodule instructions (in the .gitmodules file), figure out whether you have the submodules properly cloned yet, and if not, clone them. Then, once the submodules are cloned, git submodule update (with or without --init) will look at each gitlink, which says which commit hash ID to use out of each submodule, and will enter each submodule, one at a time, and check out the correct hash ID, resulting in a detached-HEAD setup in the submodule. This is how submodules are intended to be used. (They are annoying to use, and rather brittle, so some people call them sob-modules.)

If you don't want submodules—whether you do or don't want them is your decision, that no one else can make for you—you'll have to remove the repository-ness of the subdirectories in question. To do that, you will need to move or remove the .git file-or-directory that is found in backend/ and frontend/ in your working tree. Note that if .git is a folder full of files, it contains the entire repository, i.e., all of the history; removing it removes this history, leaving you with just one set of checked-out files. If that's not what you want to do, don't remove the .git, just move it completely out of this part of your file system.

Upvotes: 1

Related Questions