5 ms·

> So I edit the file, fix the trivial conflict, and git commit filename. This is a bit vague, but I'm guessing you mean you open up the file in your text edito

> So I edit the file, fix the trivial conflict, and git commit filename. This is a bit vague, but I'm guessing you mean you open up the file in your text editor of choice and edit it directly. What I do these days, probably originally prompted by exactly the sort of frustration you describe, is to run "git mergetool", which I happen to have configured to fire up emerge, but you can use any of a number of tools. Once I'm done, git is happy and I can just push. Initially I was a little grumpy about learning how to use emerge when before I just edited the file with all its <<<< and ==== and >>>> directly, but after learning the tool, I wish I'd been doing conflict resolution this way back when I used CVS and SVN. It's really much nicer and less error prone. So, I hope that's a helpful hint. You're absolutely right about a lot of the unhelpful & unintuitive messages and commands.

jrockway 16y ago
Isn't the message intuitive? Git usually says, "merge conflict, fix the conflict, stage the fix, and run git rebase --continue". If you follow the instructions exactly, everything works. Now, I know he wasn't doing a rebase (but should have been), but still; when you edit things in git, you stage them, and then commit them. After a merge, the index is mostly ready to be committed, except for the conflicts. So you are supposed to manually stage the fixed conflicts, and then plain "git commit". Simple. It works exactly like anyone who understands git would expect it to. Now, if you don't like the index, then git simply isn't for you. It's a core concept, you just can't avoid it. (Personally, when I was using non-git version control systems, I often had a separate working copy I used exactly like git's index. So having that built in is a joy for me.)
- kscaldef 16y ago
  No, “! [rejected] master -> master (non-fast forward)” is not intuitive. The example you give is one of the pleasantly surprising examples of a good error message from git. But, by and large, git's error messages are pretty awful.
  - jrockway 16y ago
    What else should a one-line summary of syncing master -> master say? "Hello dear user. The remote server refuses to accept your branch, because it would delete information. As a result, your request has been rejected. Please rebase and try again. If you need help, hang up, and then dial your operator." Personally, I am fine with [rejected]. I figured it out, after all...
    - stevelosh 16y ago
      Mercurial says this in the same situation: abort: push creates new remote heads on branch 'default'! (you should pull and merge or use push -f to force) Yes, it's two lines. I think we all have large enough monitors now that an extra line of output to be a bit friendlier is a good thing.
      - jrockway 16y ago
        Where does it end? Should a compiler say "unknown identifier 'foo': perhaps you need to import a header file that defines foo, or spell it better, or write code that works instead of this garbage" instead of a simple "unknown identifier: foo"? No. You just look up the error in the manual, and never think about it again.
        ryanpetrich 16y ago
        LLVM will attempt to guess the proper name of a misspelled identifier for you: http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html#spell_checker http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-re...
        phaylon 16y ago
        It theoretically ends where it's most comfortable for a wide range of people, experienced or not. And hyperbole doesn't help. Telling me to pull first so it can incorporate the remote changes isn't a big deal I think. Where does this idea come from that the interface has to be cryptic? If it isn't in there because nobody has done it, fine, that's cool and understandable. Actively arguing against better user messages is simply weird to me.
- klodolph 16y ago
  You said he should have been doing a rebase. I disagree. Almost always, if you think you should rebase, you really should merge instead.

jrockway 16y ago

Isn't the message intuitive? Git usually says, "merge conflict, fix the conflict, stage the fix, and run git rebase --continue". If you follow the instructions exactly, everything works. Now, I know he wasn't doing a rebase (but should have been), but still; when you edit things in git, you stage them, and then commit them. After a merge, the index is mostly ready to be committed, except for the conflicts. So you are supposed to manually stage the fixed conflicts, and then plain "git commit". Simple. It works exactly like anyone who understands git would expect it to. Now, if you don't like the index, then git simply isn't for you. It's a core concept, you just can't avoid it. (Personally, when I was using non-git version control systems, I often had a separate working copy I used exactly like git's index. So having that built in is a joy for me.)

kscaldef 16y ago
No, “! [rejected] master -> master (non-fast forward)” is not intuitive. The example you give is one of the pleasantly surprising examples of a good error message from git. But, by and large, git's error messages are pretty awful.
- jrockway 16y ago
  What else should a one-line summary of syncing master -> master say? "Hello dear user. The remote server refuses to accept your branch, because it would delete information. As a result, your request has been rejected. Please rebase and try again. If you need help, hang up, and then dial your operator." Personally, I am fine with [rejected]. I figured it out, after all...
  - stevelosh 16y ago
    Mercurial says this in the same situation: abort: push creates new remote heads on branch 'default'! (you should pull and merge or use push -f to force) Yes, it's two lines. I think we all have large enough monitors now that an extra line of output to be a bit friendlier is a good thing.
    - jrockway 16y ago
      Where does it end? Should a compiler say "unknown identifier 'foo': perhaps you need to import a header file that defines foo, or spell it better, or write code that works instead of this garbage" instead of a simple "unknown identifier: foo"? No. You just look up the error in the manual, and never think about it again.
      - ryanpetrich 16y ago
        LLVM will attempt to guess the proper name of a misspelled identifier for you: http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html#spell_checker http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-re...
      - phaylon 16y ago
        It theoretically ends where it's most comfortable for a wide range of people, experienced or not. And hyperbole doesn't help. Telling me to pull first so it can incorporate the remote changes isn't a big deal I think. Where does this idea come from that the interface has to be cryptic? If it isn't in there because nobody has done it, fine, that's cool and understandable. Actively arguing against better user messages is simply weird to me.
klodolph 16y ago
You said he should have been doing a rebase. I disagree. Almost always, if you think you should rebase, you really should merge instead.