I sort of take issue with this statement:
“git is bad for me because it makes assumptions about how I work that don’t match how I actually work”
I think that it's the other way around. git was built with a specific type of workflow in mind. If you take git and try to insert it into your current workflow with a minimal understand of git (or its intended workflow), then isn't it really you that are making assumptions about how the tool works, rather than the tool make assumptions about how you work?
{edit}
- I make a one-line change to a single file.
- I commit my change.
- I git push, only to be told “! [rejected] master -> master (non-fast forward)”.
(This is git’s cuddly way of telling you to do a pull first.)
- I git pull, only to be told
“CONFLICT (content): Merge conflict in filename.
Automatic merge failed; fix conflicts and then
commit the result.”
This is because you've created your local tree as such:
A-B-C
And the remote tree looks like:
A-B-D
When you run a 'git pull' it's a combination of two operations:
1. 'git fetch' or 'git remote update' which updates your local
copy of the remote tree. This is stored locally in the branch
/ (e.g. origin/master).
2. 'git merge /' most
of the time this merge is a fast-forward merge which you don't
notice at all. It's when your local commit 'C' has conflict
with remote commit 'D' that you run into an issue.
In the end your tree will look like:
A-B--D--E
\_C_/
Where E is a commit with that resolves the conflict and has two parent commit IDs which point at D and C. In general, you want to just avoid this kind of stuff in the first place by either using rebase or doing the 'git pull'
before you commit you changes,
then push them out.
[ I'm having a hard time picturing how you would have resolved this with SVN. If you have a conflict between a local file and an update that you are pulling down with 'svn up' what happens? (I've not used SVN extensively) ]
{edit}
> Well, darn. So, OK, no problem, I already fixed the conflict, so now I’ll just git merge again to get it to make its world consistent, right? Nope: “fatal: You have not concluded your merge. (MERGE_HEAD exists)”. Well, duh! I was telling you to merge, you stupid git. You’re the branches-and-merges-are-easy version-control system around here.
You're telling git to start a new merge, not complete an in-progress merge. Think of 'git merge' as 'create a commit that merges these two things together.' When you run into a conflict 'git merge' tells you, "Sorry I couldn't automatically resolve this for you, but I got you as far as I could go. You'll have to manually resolve these conflicts and create the merge commit." At this point your working directory is in a state of 'middle of a merge.' You just have to resolve the conflicts that were pointed out to you (adding them to the index once they are resolved), and run a 'git commit' to push out the merge commit.