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...
Related
Originally on my Github are some outdated styles.css and JavaScript files and others.
I was working on my project last night but didn't push it to Github or back it up. It was just saved in my local repository using a series of local, unpushed commits.
Being a newbie that I am, I did a git pull request master, and all the files in my local repository got replaced with the original styles.css and JavaScript that was in my github.
Is there a way to get those files back?
I did a git reset head#{2} where I believe the state of the repository before the pull request was, and it showed some unstaged files.
In Gitshell my command line has "master [+10 ~19 -42 !]" with the text master being yellow.
At this point, what do I do? Currently I seem to have lost a lot of work.
If you have performed commits often you can pretty much get to any of them.
Use git reflog first (https://git-scm.com/docs/git-reflog). It will show you all the interim commits you've made. Once you find a relevant one you can do git reset #commit_id.
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.
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.
I often see the below errors on doing git pull on totally untouched files which I am NOT working on.
Pull is not possible because you have unmerged files
It is clear the conflicted files have changed in the git repo. But I don't understand why git pull cannot over-write on these untouched files - which I've not touched?
What can I or my team do to avoid getting these errors?
Edited -
Along with the solution I want to understand why the errors are coming.
Just to make clear, the other team members are working on other files (say xyz). And I am working on a separate set of files having no dependency on xyz files. So if I pull the repo changes after a long time with no changes from my side in xyz, why the conflicts in those files?
use git diff to see problem files
look at this git cheat shets for usefull commands
http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf
http://jan-krueger.net/wordpress/wp-content/uploads/2007/09/git-cheat-sheet-v2-back.svg
There are some tips from my own experience. i'm not sure whether they're 100% corerect)
Split work with your team on paralel threads. Try not to work in the same files.
Try to avoid situations when 2 or more persons are adding new files simalteniously. When one added new files others should make pull as soon as possible
the last but not least - make git push very often. this will keep your project git up to date
Since git pull does not pull individual files, it's git merge phase will stop for manual correction of any merge conflicts. git merge and/or git pull (and by nature of the fact that git pull is essentially git fetch followed by git merge) is an all-or-nothing operation - you either successfully merge the changes introduced on both (or all) of the branches you are merging together, or you don't merge any of them. The catch in that is when conflicts arise that must be manually resolved - but in that situation, you are in an in-between state, having neither completed and committed the merge nor rolled it back to your previous state.
The message you are getting implies that you have previously done a git pull or a git merge, which stopped in the middle, requesting that you manually resolve some conflicts, which you have not yet done, but have rather continued on doing other stuff, and are now trying to do another git pull / git merge without ever having completed the first one.
Take a look at git status, and follow the suggested directions for either resolving your in-progress merge issues or resetting back to a not-in-the-middle-of-a-merge state.