I'm a pretty young developer and git is the only VCS I'm familiar with, and even though it has its quirks I find it quite powerful and a perfectly adequate tool for the job. In what way is Mercurial better?
Here's a quick example: when I create a Mercurial repository Mercurial doesn't say anything, while Git yells at me that it's using "master" as its branch name but I can change it with a cryptic command. After a first commit for a file Mercurial once again doesn't say anything, while Git gives me three lines of information including the permissions for the file I just added. Editing and committing a file in Mercurial with "hg commit" yields (again) nothing, while typing "git commit" in Git let's me know that it knows there's a modification but it won't go through until I "stage my change for commit".
Now, imagine you're a new user. Mercurial just did what I asked, and it even guessed that "hg commit" should mean "commit everything that's been modified". Git, on the other hand, has yelled at me about default branch names (what's a branch?!), file permissions, and bickered about me not staging my commit (what's a stage?!!). They both did the same thing but, for a new user, Mercurial did it in a friendlier way.
Heh, I've never noticed git commit including new file permissions on commit; definitely confusing/useless. Don't think "it prints less information" in general is a particularly good argument for user-friendliness though; if anything, it's the exact opposite.
Trying out hg for the first time - "hg init; echo hello>world; hg commit" prints a "nothing changed" and I have no clue how to get it to commit my file! Whereas git says 'use "git add <file>..."', and, as that's already required for starting tracking a file in both hg and git, it's not entirely unreasonable that you'll need to do "add" upon modifications too.
So in hg you have to explicitly think about file tracking and get changes for free, whereas in git you have to explicitly think about changes and get tracking for free. Obviously I'm biased, but I think "I need to tell git what changes I want committed" is a nicer model than "I need to tell hg when it should realize a file has started existing"; the former is pretty uniformly annoying, whereas I imagine the latter quite often results in adding a file, forgetting to "hg add" it, and making a bunch of commits with changes in other files as the new file is intergrated, but never actually committing the new file itself, with zero warnings.
Git's staging/index, messy as it is (and with some utterly horrible naming), is extremely powerful, and I wouldn't accept any VCS without a sane simple equivalent. Extremely do not like that "hg commit -i", adding some parts manually, and deciding that I actually need to do something else before committing, loses all the interactive deciding I've done (maybe there's a way around that, but --help and "man hg" have zero useful info on interactive mode, not even what all the different (single-char..) actions are; granted, I don't really understand "git add -i" much either, and just use a GUI when necessary). In my git workflow I basically always have some changes that I won't want to commit in the next commit.
probably_wrong|9 months ago
Here's a quick example: when I create a Mercurial repository Mercurial doesn't say anything, while Git yells at me that it's using "master" as its branch name but I can change it with a cryptic command. After a first commit for a file Mercurial once again doesn't say anything, while Git gives me three lines of information including the permissions for the file I just added. Editing and committing a file in Mercurial with "hg commit" yields (again) nothing, while typing "git commit" in Git let's me know that it knows there's a modification but it won't go through until I "stage my change for commit".
Now, imagine you're a new user. Mercurial just did what I asked, and it even guessed that "hg commit" should mean "commit everything that's been modified". Git, on the other hand, has yelled at me about default branch names (what's a branch?!), file permissions, and bickered about me not staging my commit (what's a stage?!!). They both did the same thing but, for a new user, Mercurial did it in a friendlier way.
dzaima|9 months ago
Trying out hg for the first time - "hg init; echo hello>world; hg commit" prints a "nothing changed" and I have no clue how to get it to commit my file! Whereas git says 'use "git add <file>..."', and, as that's already required for starting tracking a file in both hg and git, it's not entirely unreasonable that you'll need to do "add" upon modifications too.
So in hg you have to explicitly think about file tracking and get changes for free, whereas in git you have to explicitly think about changes and get tracking for free. Obviously I'm biased, but I think "I need to tell git what changes I want committed" is a nicer model than "I need to tell hg when it should realize a file has started existing"; the former is pretty uniformly annoying, whereas I imagine the latter quite often results in adding a file, forgetting to "hg add" it, and making a bunch of commits with changes in other files as the new file is intergrated, but never actually committing the new file itself, with zero warnings.
Git's staging/index, messy as it is (and with some utterly horrible naming), is extremely powerful, and I wouldn't accept any VCS without a sane simple equivalent. Extremely do not like that "hg commit -i", adding some parts manually, and deciding that I actually need to do something else before committing, loses all the interactive deciding I've done (maybe there's a way around that, but --help and "man hg" have zero useful info on interactive mode, not even what all the different (single-char..) actions are; granted, I don't really understand "git add -i" much either, and just use a GUI when necessary). In my git workflow I basically always have some changes that I won't want to commit in the next commit.