Live data from Hacker News

I'm going to slowly move on from Mercurial

mercurial-scm.org

71–80 of 165 posts

Re: I'm going to slowly move on from Mercurial

#71
post #59
post #54

Earlier quoted context omitted.

The index being so visible by default (as opposed to being a behind the scenes thing in most other VCS system) definitely adds some complexity. I need to sit down someday and figure out exactly how the git index fits into everything, because that is the sticking point on the one thing I used to do automatically in Mercurial that I have not figured out how to do in git other than manually. I had this hook in Mercurial…

I don't understand why you need this as a hook. In recent versions of git, "git add" on a directory updates the index to match the entire directory, with modifications, additions, and deletions.

Suppose the project looks like this when clean:

  README.txt
  src/
  include/
  doc/
  TODO.oo3
In the midst of development, I may end up with files in some of these directories that are not supposed to go into the repository. There may be output files from test runs that I'm keeping around temporarily while I debug, notes (that will be incorporated into commit messages which is why the notes files do not belong in the repository), short-lived alternative versions of some of the source or include files, and so on.

I don't want to "git add" on the project directory, or any of the subdirectories other than TODO.oo3 because I don't want to pick up those files. For everywhere except TODO.oo3, "git add -u" is what I (think I) want. It's only with TODO.oo3 that I want "git add" instead of (or in addition to) "git add -u".

Re: I'm going to slowly move on from Mercurial

#72

Earlier quoted context omitted.

Yeah by "git's network effects" you mean github. If github had decided to be hghub instead, hg would probably have won.

It seems github and bitbucket were released in the same year.

Yes, it's likely that github had more (or better connected) users at first and then Metcalfe's Law took over.

Re: I'm going to slowly move on from Mercurial

#73
post #62

Earlier quoted context omitted.

There are tons of companies using mercurial including some of the biggest ones. It's not really accurate to imply that Git won and Mercurial is dead.

There are tons of companies using Lotus Notes. git won.

What does "won" mean, concretely? I mean, if 75% of people use git and 25% use mercurial, what does it matter?

Also it's not true that a lot of forward-thinking, progressive, thought leader tech companies are using Lotus Notes. That is true of mercurial.

Re: I'm going to slowly move on from Mercurial

#74
post #59
post #54

Earlier quoted context omitted.

The index being so visible by default (as opposed to being a behind the scenes thing in most other VCS system) definitely adds some complexity. I need to sit down someday and figure out exactly how the git index fits into everything, because that is the sticking point on the one thing I used to do automatically in Mercurial that I have not figured out how to do in git other than manually. I had this hook in Mercurial…

I don't understand why you need this as a hook. In recent versions of git, "git add" on a directory updates the index to match the entire directory, with modifications, additions, and deletions.

Deletions feel a bit odd.

I mostly use "git add -p" and it misses new files, which doesn't feel right either :\

Re: I'm going to slowly move on from Mercurial

#75
I talked with an engineer from a fortune 500 tech company and they chose git over other vcs because they could have permission control; they have sensitive sub project who needs only a small set of engineers with permission to access it, but that subproject/module is part of a bigger project that everyone has access to.

I personally prefer HG over git and use it for my own personal projects, hosted on my own redmine server. I tried bitbucket, and github; the latter have s superior interface to bitbucket. which I believe why people picked github over bitbucket

Re: I'm going to slowly move on from Mercurial

#76
post #71
post #59

Earlier quoted context omitted.

I don't understand why you need this as a hook. In recent versions of git, "git add" on a directory updates the index to match the entire directory, with modifications, additions, and deletions.

Suppose the project looks like this when clean: README.txt src/ include/ doc/ TODO.oo3 In the midst of development, I may end up with files in some of these directories that are not supposed to go into the repository. There may be output files from test runs that I'm keeping around temporarily while I debug, notes (that will be incorporated into commit messages which is why the notes files do not belong in the reposi…

That's what the .gitignore file is for, or if you don't want/need to change that between other users of the repositor, the .git/info/excludes file.

Re: I'm going to slowly move on from Mercurial

#77
post #57

Earlier quoted context omitted.

> Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. I remember using Mercurial very early on in its lifetime, during my first internship at IBM, because Xen used it. Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Me…

"I find [the index] a critical part of git's culture of making small commits with one logical change each." I've never understood why the index has to be forced on everyone for every commit. Apparently it's due to a belief that everyone always just munges a bunch of changes together in their working copy in a mad coding frenzy and then later realize they need to filter and separate those changes into separate commits…

> "I find [the index] a critical part of git's culture of making small commits with one logical change each."

> I've never understood why the index has to be forced on everyone for every commit.

You can generally bypass it if making a simple commit; I use "git commit -a" all the time. But every time you use tools like "git add" on individual files, or "git add -p" on parts of files, you rely on the index.

Understanding the index also helps greatly when you need to do a merge, cherry-pick, or other similar operation; you need a staging area to work in, separate from the work tree.

Re: I'm going to slowly move on from Mercurial

#78
post #60
post #18

Earlier quoted context omitted.

Except unlike your examples, hg was contemporaneous with git. Git may have won the network effect benefit but 10 years ago it was not at all clear how it would shake out. Mercurial did gain enough users (and large users) to remain relevant, unlike some of the other options at the time.

Well yes, that's the point! It would have never been the replacement for git because it's the same paradigm. rcs: revision control cvs: concurrent check outs svn: atomic versioning (edit: originally said renames that don't suck - thanks Danny for correcting this) git: decentralised version control To replace git, you need a new paradigm. I don't know what it is, and I think few people here would. Edit: to reiterate,…

"svn: renames that aren't awful and keep history "

No, it was "atomic commits and single revision number for a change"

Remember CVS had non-atomic commits (part of the commit could succeed, part could fail), and per-file version numbers.

Disclaimer: I worked a lot on SVN :)

Re: I'm going to slowly move on from Mercurial

#79

Earlier quoted context omitted.

There are tons of companies using mercurial including some of the biggest ones. It's not really accurate to imply that Git won and Mercurial is dead.

I consider the CPython switch from Mercurial to git the final declaration of victory. I still have to understand how CPython could miss the symbolic meaning of this decision.

More Guido and a couple of vocal people than CPython. I truly hope the switch wasn't the reason for Mackall to quit.

Re: I'm going to slowly move on from Mercurial

#80
post #60
post #18

Earlier quoted context omitted.

Except unlike your examples, hg was contemporaneous with git. Git may have won the network effect benefit but 10 years ago it was not at all clear how it would shake out. Mercurial did gain enough users (and large users) to remain relevant, unlike some of the other options at the time.

Well yes, that's the point! It would have never been the replacement for git because it's the same paradigm. rcs: revision control cvs: concurrent check outs svn: atomic versioning (edit: originally said renames that don't suck - thanks Danny for correcting this) git: decentralised version control To replace git, you need a new paradigm. I don't know what it is, and I think few people here would. Edit: to reiterate,…

svn eventually got a fairly hacky answer to merging edits to a renamed file. For a long time it didn't even try, and git was a godsend compared to straightening out messes like that.
Post reply on HN