Hacker News Reader

Comment by colinhowe | Hacker News Reader

Has anyone made an alternative interface for git that tidies this up without drastically changing how you use git? Or would this condemn someone's sanity to the graveyard?

View on HN

Mercurial is essentially git with a clean interface and drastically fewer workflows. If it weren't for github's existence I'd recommend hg to anyone.

That said hg is the better choice for big software shops IMO, because of the lower training cost and because they probably won't use github anyway.

I'm using hg even with github. The hg-git extension from the github guys works surprisingly well for me. The only downsides I've found that push/pull of very large repos tends to be a bit slow and the conversion to/from git will clobber file move histories in hg, since git doesn't track file moves.

> That said hg is the better choice for big software shops IMO, because of the lower training cost and because they probably won't use github anyway.

Considering more people know git I would assume the training cost for hg is higher.

More people use git; I'm becoming increasingly convinced that few of them actually know git.

> More people use git; I'm becoming increasingly convinced that few of them actually know git.

And yet I have noticed that people find merging and branching much easier than in mercurial. Few people understand the implications of named branches in hg.

> And yet I have noticed that people find merging and branching much easier than in mercurial.

That's the first time I've heard this opinion - do you know what kind of complaints people have?

In my experience, it's much easier to say 'When you start work on an issue, start a branch called 'issue-XXX', then once you're done we will merge it into the default branch'. I've never seen much confusion in response to that.

Yeah, named branches in hg are just weird.

Not as weird as hijacking the term "branch" to mean a symlink to a ref that is not part of the history. Then again why make it easier by naming it to something more intuitive, like say, "bookmark".

Because a bookmark is usually immutable. If I bookmark "http://news.ycombinator.com has "Hacker News" it will be same URL forever.

In contrast, git branches symlink to a different ref, whenever you commit to it.

A git tag could be called bookmark intuitively.

http://mercurial.selenic.com/

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.

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

There are certainly attempts to do so. I've been meaning to try http://www.git-legit.org/

Reply on news.ycombinator.com