21–30 of 169 posts
Earlier quoted context omitted.
Also, doesn't it tell you to do thst when the conflict happens? edit, yup: $ git status # On branch master # Your branch and 'origin/master' have diverged, # and have 1 and 1 different commit(s) each, respectively. # # Unmerged paths: # (use "git add/rm ..." as appropriate to mark resolution) # # both modified: readme # no changes added to commit (use "git add" and/or "git commit -a")
Nope.
All the people suggesting various git commands he should be using are completely missing the point.
...feel better?
Now shut up and learn how to use your tools.
Duh. I've never got the hang of git either, but I figure git is for those people who don't get enough mileage out of Mercurial because they have 42 megatons of source code, or need git rebase, or just want to shock and awe their friends. But no need to hate git for that. No one's forcing you to use it. You don't like vim? Go ahead and use emacs/gedit/eclipse/perl. You don't like git? Use mercurial. Or subversion, if…
"But no need to hate git for that. No one's forcing you to use it. You don't like vim? Go ahead and use emacs/gedit/eclipse/perl. You don't like git? Use mercurial" If only this were true. But it's not: if I work on a project where my colleagues keep the source in git, then I have to use git (whereas if they use vi, I am still at liberty to use emacs). That's the problem with CVSs -- they have a lot more inertia than…
I think the move back to CVS/Subversion might be the way to go From your complaints, it sounds like you'd really like Mercurial. Give it a shot.
No, mercurial has exactly the same problem he mentioned: You want to push 'some' of your local uncommitted changes, but if the remote head has also changed you often can't. (hg shelve is a poor substitute). This happened to my team enough in practice that they rebelled and forced a switch back to SVN.
The first was that git gave very poor error messages and needed a confusing series of command-line options. In mercurial, this is much better; the pull creates a new head, and tells you what to do if you want to merge them. Commit is one-step, instead of via the staging area. It just gives more feedback, more usefully, and requires less knowledge about the underlying representation.
His second problem is common to both systems, namely that during a merge-with-conflicts you have to essentially re-commit both changes. This is actually a kind of safety feature, since the conflicted change might have screwed up something and it's up to you to make sure the code is in a good state after the merge. If the merge isn't conflicted, then Mercurial (and probably git) does it cleanly without forcing you to read over your teammate's change, which he hates doing.
All the people suggesting various git commands he should be using are completely missing the point.
I suspect these folks were OK with spending hours learning about their DVCS, but for most others, this just seems like unnecessary tedium and frustration, "When can I get back to worrying about the code?"
Someone needs to make the Mac of a DVCS, i.e. one that doesn't require a 20+ page tutorial to figure out, is completely intuitive and "just works."
I currently use Mercurial, and while I don't think it qualifies as the Mac of DVCS's, it seems to be working decently enough so far (for my simple purposes). I could learn git, but thanks to hg-git I'm hoping I won't have to.
Earlier quoted context omitted.
Also, doesn't it tell you to do thst when the conflict happens? edit, yup: $ git status # On branch master # Your branch and 'origin/master' have diverged, # and have 1 and 1 different commit(s) each, respectively. # # Unmerged paths: # (use "git add/rm ..." as appropriate to mark resolution) # # both modified: readme # no changes added to commit (use "git add" and/or "git commit -a")
Nope.
(use "git add/rm ..." as appropriate to mark resolution)