hg could be 20% better than git. For the sake of the arugment, let's say it is. git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).
Yeah by "git's network effects" you mean github. If github had decided to be hghub instead, hg would probably have won.
I'm going to slowly move on from Mercurial
51–60 of 165 posts
Re: I'm going to slowly move on from Mercurial
#52Earlier quoted context omitted.
What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?
Those would be accomplished with hg templates, not revsets. Revsets are kind of like gitrevisions(7), but much more powerful. Docs: https://selenic.com/hg/help/revsets A complete example, which appears to have some popularity in Mozilla: http://jordi.inversethought.com/blog/customising-mercurial-l... edit: Sorry, the --decorate part would be with template, the --all is kind of like a revset, and the --graph part is w…
Except for the --graph part which would be accomplished with --graph of course
> Revsets are kind of like gitrevisions(7), but much more powerful.
And easier to read and write too.
Re: I'm going to slowly move on from Mercurial
#53Earlier 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…
> Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Ouch, yet another way in which running on Windows can lead to poor technical decisions. In my own case, I really preferred hg's command congruence to SVN; git's deceptive similarity took a long time to get over. > I originally saw the index as an o…
In a way, actually, that still seems to be the case. The Mercurial community seems to be working hard on making enormous monolithic repositories much more performant and realiable, whereas a lot of Git community seems to prefer to merely respond "YOU'RE USING IT WRONG" to these issues (although I suspect the developers themselves are also working on some of the issues; it's just that I see the community at large as much more visible).
So there's definitely a sense to me that Mercurial is the better VCS because it will quietly support whatever development model you want to use, whereas Git tries to force you to use the One True Model™--and I'm firmly in the camp that development tools should support developers' habits, not force them.
Re: I'm going to slowly move on from Mercurial
#54Earlier 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. Some git users relied on cogito for another year or so, as simple things like `git-commit` still had to be manually handcrafted out of `git-commit-tree`. I wasn't there to witness this, but I repeat it because it's actual…
> 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 had this hook in Mercurial on OS X:
pre-commit = mdfind -0 -onlyin . "kMDItemContentTypeTree = 'com.apple.package'" | xargs -0 hg addremove
For those not familiar with Mercurial, "hg addremove dir ..." adds any files from the specified directory that are not already in the repository, and removes from the repository any files that were from the repository that have been deleted from the specified directory.
For those not familiar with OS X, that mdfind command is finding directories in or under the current directory that have the kMDItemContentTypeTree list in the metadata includes com.apple.package. These are directories that are logically treated as if they are single files.
Suppose I am keeping a TODO list named "TODO" with my project, and I'm using OmniOutliner to organize it. The TODO list will be in a directory named "TODO.oo3". OmniOutliner will keep an XML file in that directory that has most of my TODO list. If all my TODO list consists of is formatted text, that will be all that is in there, and everything is simple. As far as any DVCS goes, I can just treat that XML file as my entire TODO list. It will be no different than a code file, except that I edit it with OmniOutliner instead of vim or TextMate.
Now suppose I add more than just simple formatted text to my TODO. OmniOutliner allows adding files as attachments. They get copied into the TODO.oo3 tree. It also allows recording audio notes, which get stored as files in TODO.oo3. Deleting an attachment in OmniOutliner will delete the file from TODO.oo3.
So what my Mercurial pre-commit hook is doing is finding any files that have been added or removed in directories like my TODO.oo3, and adds any newly added files and removes any deleted files. Files that have just had contents changed will be taken care of by the normal operation of Mercurial.
With git, I'm not sure how to handle this. There are two main issues.
1. Where to handle this. I think the adding and removing of files from the magic directories need to occur on commands that modify the index. In particular, on "add -u". However, I don't see any hook for this. Git's pre-commit hook is, unsurprisingly, for commits, which is too late.
2. Dealing with fancy things like stashes. In general going over ever git command that affect the index and making sure that magic directories are being handled right.
It would be ugly, but I'm starting to suspect it might require putting a wrapper around the git command itself, which is kind of ugly.
Another possibility is a pre-commit hook that just checks to see if any magic directories have added or removed files, and if so aborts the commit and alerts the user that they need to "git add" or "git rm" those files or add --no-verify if they want to commit anyway. It wouldn't be as clean as it was in Mercurial, but it would at least be an improvement over relying on noticing in the "git status" I almost always do before committing that I've got some add/removes in a magic directory that need to be taken care of first.
Re: I'm going to slowly move on from Mercurial
#55hg could be 20% better than git. For the sake of the arugment, let's say it is. git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).
hg-git[1] lets hg interoperate with git repositories, which helps a bit with the network effect problem. I'm currently using hg-git for my projects and I am loving it because I much prefer the hg UI (both the command line and tortoiseHg) to git's UI. [1] https://bitbucket.org/durin42/hg-git
If you like hg, but want to exploit git's network effects, I strongly suggest checking it out.
Re: I'm going to slowly move on from Mercurial
#56Earlier quoted context omitted.
hg came before git, you have your network effect backwards. The reason git ended up overtaking mercurial is because git is more flexible. Programmers for closed-source enterprise projects worldwide flocked to git because git can be massaged into any existing development process almost painlessly. Mercurial, in contrast, is "opinionated". (Before you mention github -- the timeline here is also backwards, github became…
I'm curious what makes you say that. From my point of view the exact opposite is true. Mercurial allows many different workflows (bookmarks, anonymous heads, named branches, topics), but with git you're pretty much stuck with the "standard feature branching" workflow.
The experience of migrating to DVCS's. (Anecdotal, I know, but still...)
>...but with git you're pretty much stuck with the "standard feature branching" workflow.
Git is a loose collection of file manipulation utilities, it can be cobbled together to support even the most insane workflows.
Re: I'm going to slowly move on from Mercurial
#57Earlier 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. Some git users relied on cogito for another year or so, as simple things like `git-commit` still had to be manually handcrafted out of `git-commit-tree`. I wasn't there to witness this, but I repeat it because it's actual…
> 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'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? That happens to me from time to time, but it's not the common case. When it does happen (since I use mercurial) I can use use tools such as commit --amend, or commit , or record or crecord to filter and separate the changes in my working copy into separate commits. I believe even git has some of those same options.
Re: I'm going to slowly move on from Mercurial
#58Earlier quoted context omitted.
> Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Ouch, yet another way in which running on Windows can lead to poor technical decisions. In my own case, I really preferred hg's command congruence to SVN; git's deceptive similarity took a long time to get over. > I originally saw the index as an o…
Hg worked on Windows from the beginning because it was written in Python. Python best practices make it pretty easy to avoid Windows-specific quirks (use os.path.join for directory munging, and don't use hard links). Git was a bit of C at first, which got wrapped in successive levels of bash and Perl, neither of which were particularly well supported on Windows 16 years ago.
Not that this has changed much, the CLI git has been renamed to "git on windows" but fundamentally you're still installing msys (2) to run git.
That issue is greatly mitigated by the existence of libgit2 though, it builds natively on windows (and just about everything else) so windows git (GUI) clients need not depend on CLI git.
Re: I'm going to slowly move on from Mercurial
#59Earlier 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…
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…
Re: I'm going to slowly move on from Mercurial
#60hg could be 20% better than git. For the sake of the arugment, let's say it is. git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).
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.
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, none of this has anything to do with whether git or hg is technically better.