I pushed changes to a branch with a detached head using IntelliJ. It gave me an obscure warning but accepted my push without forcing. Then I checked out the branch and all my changes disappeared. Where are they and how do I get them back?
If you type git reflog, it will show you the history of what revisions HEAD pointed to. Your detached head should be in there. Once you find it, do git checkout -b my-new-branch abc123 or git branch my-new-branch abc123 (where abc123 is the SHA-1 of the detached HEAD) to create a new branch that points to your detached head. Now you can merge that branch at your leisure.
Generally, if you check out a branch after working on a detached head, Git should tell you the commit from the detached head you had been on, so you can recover it if you need. I've never used SourceTree, so I don't know if it relays that message. But if it did display that message, then you should be able to use that to find the commit, and again use git checkout -b or git branch to create a branch from that commit.
Related
I have just encountered an issue I have never seen before and can't find any help on.
I run a git master repo on the live website in our hosting environment, and a bare origin repo on the same server. All our developer commits go to the bare origin master, which has a post-receive hook to push each commit to the master repo so that the push is reflected in the live site files. The only annoyance is that whenever we get WordPress updates, we have to commit on the master repo, then push it back to the origin repo so that our developers can download those updated files.
Problem: Today, I went to commit a WordPress plugin update, and the commit worked fine, but the push gave the following cryptic error that I cannot find any help on:
git push origin master
Counting objects: 344, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (323/323), done.
Writing objects: 100% (344/344), 1.76 MiB | 5.61 MiB/s, done.
Total 344 (delta 237), reused 14 (delta 1)
remote: Resolving deltas: 100% (237/237), completed with 226 local objects.
remote: Running post-receive (git pull origin master):
remote: error: index uses ▒yz▒ extension, which we do not understand
remote: fatal: index file corrupt
(The weird symbols around the letters "yz" reads as "<B3>yz<AC>" when I run git diff)
If I run git status on master (cannot be run on origin as it is a bare repo), it repeats the last two lines of output. If I run git log on both repos, they look normal, but the origin is of course one commit behind the master, because committing to master worked, but pushing to origin failed.
I have never heard of this "yz" extension before, and as far as I can tell, no one else has either. All I did was a commit and a push and the push failed. We do not use any such "yz" extension, we use vanilla Git, do very basic pushes and pulls, our post-receive hook is about a 5 line script which just auto-pushes every commit from origin to master and resets file permissions to ensure they're readable by the web server. The only weird thing we're doing is using Git to manage a WordPress site for version control. All developers use TortoiseGit on Windows without any special settings or any sort of plugins.
I have seen plenty of questions and answers about corrupt indexes, but nothing like this.
I have not tried anything yet as I'm not sure what to do, don't understand the internals of Git, and don't want to break anything, but we need to be able to pull and push and cannot until the repos are in sync again.
Everything prefixed with remote: came not from your Git but from their Git—the Git your Git called up, at the URL you used when you ran git push.
It's their Git that is complaining about their Git's index. This is probably a file corruption issue on their machine. You need to get them—whoever "they" are—to check out their system. If all looks OK, they should probably just remove and rebuild their index files.
(If "they" / "them" is really you, go over to whichever machine(s) are involved, inspect them carefully for damage or disks that are on fire or whatever, and if all looks good, remove and rebuild the index files.)
Alright, here's what I did:
Because I did not want to lose any changes to the master repo (corrupt index), as the changes needed to be kept and also pushed to origin (working index), I ran the following:
rm .git/index
git reset --mixed
(mixed is the default option)
According to the documentation:
--mixed
Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.
Thanks to torek and bk2204 for your help in understanding the situation, and a little bit of googling to figure out the safest process for resetting an index without losing any committed or working files
I have two users sharing R code on a TFS Server. One user is in RStudio (v1.0.143), the other in Visual Studio 2015.
When I look at the code history, it looks like the RStudio user is always doing two commits instead of one: the first is the legitimate commit, and the second looks like a merging of branches, with the comment "Merge branch 'master' of ..."
How do I stop this constant branch-and-merge? Is there a way RStudio can just do regular commits?
This is the default behavior of git when there's at least one commit locally that is not in the remote (and vice versa) when the push occurs. Git creates a merge commit to combine the branches that have diverged.
You might ask your RStudio user to perform a pull immediately before they make their commit, and to perform a push immediately after, so that they don't wind up with a divergent branch.
In git parlance, what you want is for the RStudio user to be able to do a fast-forward merge when pushing changes. Hope that helps!
Does git flow avoid fast forward merges for better reporting?
While testing git flow I see not only the commits from my release branch on master & develop but also merge commits. I thought I'd only see release branch commits and then a fast-forward as git adjusted master & develop to point to the new commits.
As a very simple case, I expected no merge commit requirement since no other changes appeared between the time of release branch start and finish.
What drives the merge commit requirement or did I miss something?
Thanks
Peter
Scenario: Release Stabilization
Create release branch (git flow release start 100.0.0 develop)
Push for collaboration (git flow release publish 100.0.0) (it's just me, so I'm collaborating with myself)
make and commit 1 change on release/100.0.0
Finish release (git flow release finish)
RESULT
local develop +3 commits to remote
HEAD merge tag to develop e191707
HEAD -1 e0040cb merge from release branch
HEAD -2 e7cdc02 release branch change
local develop +3 commits to remote
HEAD merge tag to develop e191707
HEAD -1 e0040cb merge from release branch
HEAD -2 e7cdc02 release branch change
local master + 2 commit to remote
HEAD e0040cb merge commit
HEAD -1 e7cdc02 stabilization change
It seems that git flow uses git merge --no-ff as its default (see git flow considered harmful). I don't think that choice help improve understanding and creates unnecessary noise. I expect us to use git flow provided we can sort out when to use ff
I have a conflict and I am unsure how to resolve it.
The error I get when doing svn udpate is:
Tree conflict on 'wp-content/plugins/eventON'
> local dir replace, incoming dir edit upon update
Select: (mc) keep affected local moves,
(r) mark resolved (breaks moves), (p) postpone,
(q) quit resolution, (h) help:
I do not understand what this is trying to tell me.
I would like it to replace the local version of the web server's plugins/eventON with the version that is in the SVN repo.
Background info:
The error message may be the result of deleting the folder that was being versioned through Wordpress admin panel, and then copying another one in the same location (a bad attempt at updating a plugin while forgetting how SVN works).
I guess that running the update through Wordpress deleted the .svn folders that were present in the plugin (the needed stuff for SVN to work properly).
So you could delete the new, unversioned eventON folder that you have copied in your repo, and run a svn update from one directory above (wp-content/plugins), in order to retrieve the old, versioned plugin.
If it does not work, it may be easier to delete the repository and checkout a fresh version...
Then, you will be able to update your plugin manually through SVN, and commit it.
As long as you already know that you want the server's version and not the local, this shouldn't be too difficult to resolve.
Identify which files are conflicted with svn status.
Since you want to keep the repository's version, you probably want to remove any conflicted files that svn has added from your working copy. They will have an A next to them in the output of svn status. In your case you should probably back them up first, since svn can't get them back for you since they're not in the repo yet. Now use svn delete --force my/fileToDelete. You don't need to delete anything not related to the tree conflict if you have made other changes you want to keep.
Run svn resolve --accept=working my/treeConflictFolder on the remaining folder that is conflicted (it will have a capital C next to it in the output of svn status)
The tree conflict should now be resolved, so you should be able to commit and update normally.
Further reading: http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html
I wonder what the difference is between
bzr checkout ./MyProject MyProject.dev
# later followed by a
cd MyProject.dev
bzr pull ../MyProject
and
bzr get ./MyProject MyProject.dev
# later followed by
cd MyProject.dev
bzr pull
As far I can tell the only difference is:
bzr get sets the pull location.
bzr checkout doesn't set the pull
location, so it must be specified
the first time you pull.
Are there other differences?
In the case of bzr checkout you should not use bzr pull, but should use bzr update instead.
bzr get is alias of bzr branch which is roughly equivalent of git clone.
bzr get creates a branch, whereas bzr checkout creates a checkout. With a checkout, any revisions you commit to MyProject.dev will also be committed to MyProject.
For more detail, see the checkout tutorial.
This is one of the way cool features of Bazaar that doesn't get enough press: the ability for people to work the way that makes them comfortable, even on the same shared repository.
Have some git or other DVCS devotees? Fine. Have them use bzr branch.
Have some old-school svn guys who just can't wrap their heads around all the branching and merging? "Wait...I have to create a branch, do commits, then merge my branch, then push my branch? How stupid, I just want to commit!" Fine. Have them work with bzr checkout.
This type of flexibility is what draws me to Bazaar, despite the fact that git is wildly more popular and faster.
Basically you have the option of not being tied to the branch you got the code from: if you want a standalone copy use bzr get, if you want to be automatically bound to the original branch: use bzr checkout.
If you change your mind later and want it to behave more like SVN, you can do a bzr bind and any commits you make will automatically be committed to the parent branch.