I have a project which was bound to the remote server on github, but somehow it stopped working, so I deleted the remote origin folder through the Organizer and reconnected fresh.
But now, I have changes made to the project that are not yet pushed to the remote server.
I am trying to push, and I get the error:"Your working copy is out of date. Try pulling from the remote to get the latest changes, then push again.".
But this is not what I want to do, because it will erase all my local changes!
Actually, the error message is incorrect, because my working copy is newer than the version on the remote.
Please advise.
Thanks!
Usually when I forget to pull, git does not overwrite my local changes.
Still it is worth being safe. Store your local commits as a stash, then pull and apply the stash.
See this stack overflow answer here:
git stash
git pull
git stash pop
Related
I'm working on a project in Rails and was using a CSS framework that came with some images. I later decided to use something else and no longer need the images. I deleted them, committed my changes to github but now every time I I commit to github it pulls the files I already deleted. How do I keep it from doing that? I want those changes gone for good, not readded to my project every time I merge.
After committed have you push your change to repository. Please do following
delete images
git status
You will see files changed are comming in status, if images comming than go head and continue, you can either run git add . to add all files or
git add images_name_or_folder
git commit -m "Removed images"
git push
Now check and do `git pull` to check if all images gone.
I fixed this by doing a force push. I don't understand the problem but I forcing the push fixed it.
I am working on a Rails project!
Excuse for not adding .gitignore
I have accidentally committed and pushed 'database.yml' in to my feature branch. A pull request was created from the feature branch to master branch a few days ago and is not yet merged. There are multiple commits done as part of this pull request and the commit containing 'database.yml' is the fourth last commit.
Others are also working as part of this project and they are merging the changes to master and we are pulling those changes in to our feature branch in-between. Thus, in our feature branch, we have got commits from others which are done after the faulty commit.
so I wish to do a 'git rm' and 'git push' the same file again to resolve this issue (as the PR is not yet merged). Will that create problem?
If you remove the database.yml that will be another commit on top, and nobody will be affected.
Notice, however, that the database.yml will still be part of the history and can be accessed via git log. If that file contains sensitive information, it will be findable by others.
Delete the file from your local system then add the changes to a commit using
git add <FILE_PATH> command and then commit and push the changes and it should be fine.
The right way to remove it properly is to reverse the changes you made to the file and commit it.
Another, dirtier way, is to open the commit and remove the changes and force push it to the repo. But you need the proper rights for this. Others will also have problems if they try to pull changes then.
I was trying to push my code (ruby on rails) stored in GitLab to production. As it didn't work, I tried to check git repository and accidentally created a new one through project/repo$ git init.
After that I got a message about Initializing a new repository.
According to other solutions for accident git init, it wouldn't be a problem if I initialized a new repository in already existing one, but in this case I would get the Reinitializing existing repository message, which I didn't get. So should I just delete the repository via rm -rf .git? According to this I accidentally started a new git init on an existing git project, what do I need to get it back to normal?, it will do me no good, or it might be different situation?
I have very little technical knowledge, so if you could explain "for dummies" that would be great!
Update: I deleted the repository and everything works now.
What the full message about "initializing a new repository"? In short, yes all git related files are stored in the .git directory so if you delete it you can start fresh. That sounds like a good idea considering that you won't loose anything yet.
Note that git init only sets up the repo to commit. You still need to make an initial commit in order to push to your remote on GitLab. You do this via git's commit command.
I'm wondering how this is possible.
I made quite a bit of changes to my rails project (deleted some stuff, edited files, added files, ...) as I implemented a whole new design.
And now I want to commit my project and push it to github
git merge new-view
git add .
git commit -am "implemented the new design"
git push origin master
Now when I pulled the changes on another computer I noticed that not all of my features were working. (for example the image slider wasn't functioning).
When I go trough the files, it looks like all the changes I made are there, but I must be missing something because both projects are not behaving in the same way!
Even when I clone the project again from github (on the original computer with the working projectfolder), the feature still doesn't work.
git clone projectname
Now in my old folder I can't push any other changes as status tells me that my branch is up to date with origin/master
git status
I figure that I can just delete the github project and upload it again, but that's obviously not the way this is supposed to be done.
Any ideas what could've gone wrong?
Make sure that no important files are being ignored- see this answer
Make sure everything is truly committed. git status and git status --cached
Make sure any databases are initialized, migrated and populated with the same data.
Check browser caching.
I had been using a Subversion for my source control, combined with git ONLY to deploy (push) to heroku. My pattern was: Update local working copy from latest master at remote subversion repository. Then do git commit and git push heroku (Git was set to ignore .svn stuff). This working copy I only used to push to heroku, I had another subversion folder for doing live development, and committing to the remote subversion repository for tracking.
I have now switched to git fully. I did a complete import from subversion into a new remote git repository. I've successfully been working on my local working copy of the git repo (origin), and pushing changes when it suits me (also collaborating with one other developer, but I basically run the operation).
MY Question:
I would now like to return to my OTHER git working copy that I had previously been using to push to heroku (that has .svn/ stuff in it as well). I'm thinking of just adding my new git repository as an [origin] entry in the .git/config.. pulling the latest changes from my new git remote, and pushing to heroku, but I'm wondering if it will freak out.
It will try and merge and get confused won't it? AND, even if the pull worked, will the heroku remote get confused about a push that originated from some new git repo?
I could clobber (delete) that working copy (used to push to heroku from subversion), and make a new clone of my new git repository, then add heroku to the .git/config. But I'm concerned pushing to heroku will still cause it to get confused, since I used to push from a different working copy.
Any advice would be great!
Thanks in advance!
If I understand you correctly, you want to switch back to the former SVN repository as your working copy, and you want to preserve the old SVN history?
There are a couple of options available.
Push the recent changes from the new Git repository to Heroku, then switch to the old repository and pull from Heroku. This will bring you old repository up to date.
Temporarily change the URL in the old repository's config file to point to the local path of the new repository. Pull the recent changes from there, and then revert back to the Heroku URL when done. This will also bring your old repository up to date.
The first option is the most expedient, and the second is the long way round. Either way, you will have the same net result of an up to date local repository containing all history. The surplus new repository can be disposed of in either case.
Edit:
To address your concerns about whether Heroku will care about the origin of the commit, in brief, no the repository on Heroku is another git repository that accepts commits from authenticated users.
As long as the credentials are correct, the originating repository does not matter. This is the beautiful thing about DVCS - there is not one controlling or corruptible repository - It is entirely possible for you to now clone from Heroku on another machine and continue work from there. As long as your credentials are the same, the history will show any and all commits you push, but does not care where from.
If your desire is to simply use a clean repository to work with, the new one will be the favorite. The old one can be deleted without ill effects.
To prove this - check the SHA-1 hashes for a commit in both new and old repositories, and you will see they are identical. The hash is unique for all commits, and can be used to check the code integrity at all times. There will never be more than one change for any given hash.
As a side note, the repository is portable in that it is entirely self contained, and can be moved around freely on your storage space, or even be used on external storage such as a USB thumb drive.