git merge
I used to work with a guy named Jay who, when encountering a particularly complex or difficult programming challenge, would state aloud, "Now that's powerful."
git is a powerful tool. And it really is but, my God, it sure has a way with obscure error messages.
At some point you'll not be able to pull changes from the master (I want to call it the HEAD via cvs, svn concepts) because you are in the middle of a conflicted merge. You'll know this because you'll see this message:
Unlike svn update, which will pull the latest changes and automatically merge what can be merged and insert diffs where it can't, you need to manually merge the changes. You can open the diff tool with this command:
mergetool doesn't actually work out the diffs---you do. It opens a default diff editor for each file in need of merging, which may be vimdiff if nothing else is installed on your system. You compare the differences, edit to make any changes, and save the file. mergetool then asks you if the diff is complete, and if so, opens the next file. This continues until you have resolved all conflicts.
By the way, mergetool works with a number of different diff tools. See the man page for a complete list. I went with meld, the gnome diff editor. Once installed via apt-get, mergetool opened meld without any additional configuration. Not quite sure how it knew which one I wanted, but it guessed and got it right.
So now you can pull the latest changes, right? Not so fast. You might see an error like this:
Ah, what does it all mean? I find this to be common thought when using git. Clemens Buchacher had the answer:
Yes, that would be me: a fellow used to the "update and commit" style workflow.
For my case, I just had to commit once and then I could, finally, pull changes I had committed on another server.
git is a powerful tool. And it really is but, my God, it sure has a way with obscure error messages.
At some point you'll not be able to pull changes from the master (I want to call it the HEAD via cvs, svn concepts) because you are in the middle of a conflicted merge. You'll know this because you'll see this message:
You are in the middle of a conflicted merge.
Unlike svn update, which will pull the latest changes and automatically merge what can be merged and insert diffs where it can't, you need to manually merge the changes. You can open the diff tool with this command:
git mergetool
mergetool doesn't actually work out the diffs---you do. It opens a default diff editor for each file in need of merging, which may be vimdiff if nothing else is installed on your system. You compare the differences, edit to make any changes, and save the file. mergetool then asks you if the diff is complete, and if so, opens the next file. This continues until you have resolved all conflicts.
By the way, mergetool works with a number of different diff tools. See the man page for a complete list. I went with meld, the gnome diff editor. Once installed via apt-get, mergetool opened meld without any additional configuration. Not quite sure how it knew which one I wanted, but it guessed and got it right.
So now you can pull the latest changes, right? Not so fast. You might see an error like this:
fatal: You have not concluded your merge. (MERGE_HEAD exists)
Ah, what does it all mean? I find this to be common thought when using git. Clemens Buchacher had the answer:
The following is an easy mistake to make for users coming from version
control systems with an "update and commit"-style workflow.
1. git merge
2. resolve conflicts
3. git pull, instead of commit
Yes, that would be me: a fellow used to the "update and commit" style workflow.
For my case, I just had to commit once and then I could, finally, pull changes I had committed on another server.
Comments