Hacker News Reader

Comment by varikin | Hacker News Reader

This may seem like a joke, but having used Hg a little bit, I do think it has a superior interface. The error messages are clear, the commands are intuitive. The command addremove is genius.

But I still use git because I already grokked it before I learned hg.

View on HN

I learned hg before git and the experience of switching to git was shockingly bad. I'm comfortable in both now and the big thing I'd miss if I went back to hg would be git stash (and I'm sure there's a hg plugin for it).

> I learned hg before git and the experience of switching to git was shockingly bad. I'm comfortable in both now and the big thing I'd miss if I went back to hg would be git stash (and I'm sure there's a hg plugin for it).

What about the index? Or the branching (bookmarks kinda work now I think), or the better remote management?

I personally hate the index. It gets in my way far more often than I actually make use of it.

How does it ever get in the way? Just add `-a` and you can essentially ignore that there is an index on commits.

Let's say I modified an existing file (not staged) and then git add a new file. It is a work in progress, and the two changes are not supposed to be in the same commit.

Now, what can I do to see all changes I have made so far?

I have done this many times with subversion (svn diff) and mercurial (hg diff). Git's index just get in the way.

You're touting these as positives for git but in the context of training a large group to use a new VCS they are a negative.

I have found branching in Git to be a pleasure to teach, even to large groups. There is nothing I have to hide about them, implementation or otherwise. "This is how it works and this is what you can do thanks to that"

That's interesting. I learned hg first and moved to git after being frustrated with hg's limitations. Yeah, git could use an overhaul on some of it's command line interfaces (using the index on different git commands: --cached, --stage, --index), but it's so much better overall that those things become minor quibbles.

Switching to git was very easy for me after hg screwed my repo. And git had much saner branching back then, not sure if anything changed in mercurial land.

> The command addremove is genius.

Why? I find that in the middle of a big project I have lots of stupid files strewn about that I absolutely don't want checked in (TODO lists, patches I'm considering, copies of large log files I'm investigating, etc). I always add things explicitly and delete explicitly, otherwise I'd get random junk checked into my repo. How do you keep your repo clean enough to actually use automatic commands like that?

Put that type of thing in .hgignore.

Isn't that checked in like .gitignore? I'd rather not put stupid local stuff into a file that the rest of the team shares. And if I don't commit it then I'm stuck with a local file that always has changes, which is also begging for trouble. It also implies that I name things in some consistent way or that I add a lot of files into the ignore file.

I guess other people just aren't as messy as I am?

You can keep multiple ignore files. Then .hgignore can be shared by the whole team (if you're working in C, you're going to ignore .o files, for instance, and so will everyone else). Look up the ui.ignore hgrc option to add more files (presumably one of which doesn't sync).

> The command addremove is genius

That's the default of what git does even without a command.

No it's not.

    [alias]
    addremove = !git add . && git add -u

That will do it though, so it's not too hard to add.

git add -A

Git does it on `git commit -a`.

No, it doesn't.

    -a, --all
        Tell the command to automatically stage files
        that have been modified and deleted, but new
        files you have not told Git about are not affected.

Ah, it's too long since I used hg. Thought it only picks up deletes.

No, git doesn't track renames — git _guesses_ them

Reply on news.ycombinator.com