I had made some changes to the code and wanted to create a new branch to reflect those changes.
Using the github software on mac, Peak Meme (162), I clicked on branches, clicked the + sign next to master, created a branch called updating-design. I think I clicked publish.
Then I went into PHP storm and all the code from the last few days was deleted.
The code was deleted from my local clone. I was trying to push the changes I had made through the new branch.
You can use the git reflog and retrieve it from the command line
It sounds like you were already working on another branch without realizing it, and now you've checked out a new branch that doesn't have the work. Double-check your list of branches.
Git is pretty adamant about not deleting your work just because you switched branches.
Related
First I have a master branch in my remote repo on the internet. And I know if I changed my local files, how to update my local changes to the remote repo. Now the problem is, if I don't want my new changes in my local tracked files, how to return back using updating from the remote repo in github?
I have tried the following things:
I use
git checkout origin master
to get to master repo.
I make sure that one tracked file, named main_32.f90 is changed a little bit in the comment line.
Then I use
git pull
it turns out that everything is up to date.
Already up-to-date.
I then checked the main_32.f90, it is not the original one but the changed one in comment line. So it means that the git pull is not working.
So how to do it?
If you don't want to keep your local changes, you can do a hard reset to a pointer, branch, sha1, etc to discard all changes. git reset --hard HEAD.
Use this kind of aliases to have a pretty view of your working tree if you are a console fan and don't want to use any GUI as suggested by other users.
Below is the situation which explains what's the matter about git.
I was using the 'develop' branch and already made several changes to the local files such as .sql, .java, .js...
I made a local branch called 'develop_some_future' since my boss wants to confirm my changes before merging main 'develop' repository.
Apparently my local file changes #'develop' branch have applied to 'develop_some_future' branch and I started editing local files again.
For some reason, I tried to pull the files that my co-workers already committed, but it has failed(Probably I couldn't set 'develop_some_future' branch well). So, I changed current branch to 'develop' branch and tried to pull them.
Fortunately it got worked, and then I tried to back to the 'develop_some_future' branch.
A dialog pops up suddenly while changing the branch and asked me that 'your local change for "~~~.sql" would be deleted since it's not committed yet. To avoid this, please commit that file or choose reset.'
Because I thought only '~~~.sql' would be changed to the latest committed state and that was not a problem, I selected 'reset' button, but unfortunately all local changes have gone.
Anyone knows how can I retrieve the date before reset?
I found that both 'git reflog' and 'git reset HEAD{}' commands are useful.
However, git reflog shows only commit, merge, and checkout changes and so I can't find reset status at all.
I'm afraid your files are gone for good, unless you had previously staged the file somehow (add or stash save).
If it had been staged, a blob object was created by Git which is now dangling (git fsck will tell you dangling objects). You can then resurrect the file by writing the blob's content with git cat-file to a new file.
If not, your'e screwed, and you have to do your work again.
It seems the problem arose in the first place, because you thought that unstaged/uncommitted changes belong to the current branch. They do not, and only live in the working directory. They will be carried over when switching branches (unless, of course, the same file was modified in the branch. Git will then refuse to checkout the other branch).
I read all SO questions about this issue, and I still can't resolve it.
I am using TortoiseHg. I worked on a side-branch, and now I want to merge it back to the main branch. I pulled all changes made in both branches, updated to the main branch, and merged (and committed). But still when I try to push all this, I get the "abort:push creates new remote head" message.
I also tried (as was suggested in one of the questions in SO) to close the branch using the --close-branch option.
The only thing I did not try is to 'force' push.
Any suggestions? Or is force-pushing the only option?
Just for everyone else that runs into this problem.
What caused this problem for me were some local revisions on the default branch that I didn't push before I started to work on a new branch.
I had merged the latest revision I pulled for the default branch with my new branch, but these leaves your local changes to the default branch committed but un-pushed.
If you try to push them, it's not your new branch that is creating a remote head, it's the un-pushed revisions to the default branch that is creating a remote head.
When I stripped out those revision with hg strip -r 1234
hg push --new-branch
went perfect.
What put me on the right track was
hg heads
With showed I had two heads that both had the name of the default branch with different revision numbers.
I just tried a similar setup, and I get the same warning. Apparently, although the second head you are trying to push is closed, it is seen as another head during the push. And closing both heads does not seem to be pushable either.
You can force the push, it should be ok, but you could eventually get the same issue if you keep multiple heads on your visualization branch, like you already have with changesets 14 and 20. To solve the issue once and for all, I would instead suggest to merge both changesets (14 and 20) and reclose the final head.
Thanks for the answers, I definitely learned some new tricks.
What I ended up doing, is cloning an early revision from the remote repository, that is, a repository that doesn't have all the commits of my merges etc. I then pulled the change-sets, merged, and committed. Then the push finally succeeded.
It was basically the same steps I tried to do before, but apparently on the first (unsuccessful) trial I broke it down to more steps than were needed, and something went wrong at some point.
Try this solution,
Assumption. You have enough rights to close and create the branch in the remote
This happens because you are trying to rewrite the history. Just try hg push -f which will create two heads in the remote repo, which you might not
So the first login to your remote and close the branch, now come to your local and push using hg push -f. The necessary new branch will be created automatically with the original condition as it was before.
Ok, I've got a problem that I have no idea how to go about solving.
First, a bit of history:
I pulled from my upstream to bring in changes and merged them with the branch I was working in. At the time, I may have been using a console window with root access. I say this because I noticed a day later I couldn't save to a lot of the files in my local repo. I noticed the owner / group had been changed to root and permissions were 644. After going through and hunting down all of the screwed up files, I then pushed some changes I had made back to my remote working branch.
A week later (now), and I've added several other commits to an open pull request from my remote branch. In the middle of them was the commit I made after fixing my local repo file permissions. I noticed it has some 1200 "empty" files (no changes). I'm a little concerned that merging this pull request upstream could cause big problems and I have no idea how to remove this one commit or if it's even possible...
I tried creating a new branch and using cherry-pick to get all but the one commit, but I've removed files and couldn't merge the older commits that saw a "conflict" between the file that existed at the time and one that no longer exists in the local repo...
Anyway, any thoughts?
The solution I used was to reset my local branch to the commit just before the one that I didn't want. I then copied and pasted the commits after the failed commit into code, recommited, and pushed toa new branch. Long way around, yes. But it wasn't bad as I didn't have a lot of code to fix. A simpler method might have been to use cherry-pick to pull the later commits into my reset local branch, but I tried that at one point and had problems...
There is a branch in github that I can access via Eclipse/eGit. A colleague then created a branch off of that existing branch, but that new branch is not visible to me in Eclipse or from the command line. What do I need to do to make that branch-off-of-a-branch visible to me?
Your colleague needs to push it to Github, then you need to do a fetch to get it from Github. Then, if you want to work on that same branch yourself, you need to create a local branch based on it, which, in recent Git versions, can be done simply via git checkout <simple branch name>.
Update: So when you have trouble fetching remote refs, you should check that your fetch refspec looks something like +refs/heads/*:refs/remotes/origin/*, or you won't see the whole picture.