16 ms·

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,

• JoshTriplett 11y ago
  > 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 Mercurial for that reason, because they had developers on Windows. Unfortunately, Mercurial took longer to develop some of its infrastructure, such as a repository structure optimized for performance, fast branches without making a separate working directory for each, and history editing capabilities. Today, as far as I know, Mercurial does have all of those things (some through plugins). > 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`. Many people (myself included) also used cogito as a crutch for a while longer, until really internalizing the value of the git index, because cogito defaulted to bypassing the index. I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each.
  • zeveb 11y ago
    > 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 obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each. Same here, on both counts. I'd never go back, now, but it did take time to understand the benefits.
    • ngoldbaum 11y ago
      I do the same thing with mercurial's "hg commit -i" interactive interface. There's also a very nice curses interface for interactive hunk selection which is currently behind an experimental config flag but is shipped with the core application.
    • oblio 11y ago
      > Ouch, yet another way in which running on Windows can lead to poor technical decisions. That's quite dismissive of Windows...
    • pcwalton 11y ago
      > Ouch, yet another way in which running on Windows can lead to poor technical decisions. I didn't see any indication in the parent comment (or in general, really) that Windows support was the cause of Mercurial's difficulty in implementing those features.
      • apetresc 11y ago
        He means that Mozilla devs running Windows led them to adopt Mercurial (which was, in his opinion, a "poor technical decision"). Not that Mercurial made poor technical decisions as a result of supporting Windows.
    • theandrewbailey 11y ago
      > Ouch, yet another way in which running on Windows can lead to poor technical decisions. I've never heard from anyone that choosing/using Mercurial was a poor decision. Are you biased?
      • zeveb 11y ago
        > I've never heard from anyone that choosing/using Mercurial was a poor decision. I liked hg too, but as the passage of time has indicated choosing it for one's project would have been a mistake, as git has effectively won.
  • mrighele 11y ago
    > I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each. How is this different from mercurial ? I know that the latter doesn't have the index, but is there any practical difference from the point of view of the user ? In Mercurial you can easily commit a subset of the files, or even a part of a file if you use the record extension.
    • jordigh 11y ago
      > if you use the record extension. It's now part of core with `hg commit -i`, although it's still experimental.
    • pekk 11y ago
      Have you used both? You can commit a subset of changed files in most version control systems, but it isn't smart because you didn't test that state and it's relatively easy to garble files. Not having the index is a very practical difference for users, because it means that you do not get any editable "staging" commits, only commits that will be on the permanent record.
      • mrighele 11y ago
        Thanks for clarifying, my experience with Git is much more limited than with Mercurial, so it wasn't clear to me that the index is a sort of editable (or partial?) commit (of course now it looks quite obvious). I understand the appeal of that, in fact Mercurial acquired similar capabilities during it's evolution, thanks to a number of extensions (for example histedit [1]) [1] https://www.mercurial-scm.org/wiki/HisteditExtension https://www.mercurial-scm.org/wiki/HisteditExtension
      • krupan 11y ago
        But nothing in git (or any dvcs, really) is "permanent record" until you share it with others. git users are very proud of git's history editing capabilities, in fact. So no need for an index, just commit, and edit that commit if needed.
      • 11y ago
  • tzs 11y ago
    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 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.
  • krupan 11y ago
    "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? 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 <list of filenames>, 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.
    • ngoldbaum 11y ago
      In recent versions the "record" extension has been replaced by "hg commit -i". Many other commands support interactive hunk selection as well.
    • JoshTriplett 11y ago
      > "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.
      • krupan 11y ago
        "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." Actually, with mercurial I don't need a staging area to work in separate from the working copy to perform merge, cherry-pick, or other similar operations. The index appears to be needless complication.
  • rbehrends 11y ago
    A couple of technical notes: > such as a repository structure optimized for performance Actually, repository structure hasn't fundamentally changed (unless you count the RevlogNG change in 0.9). There have been changes so that data on disk compresses better (the generaldelta change) and there's more underway to support new features (such as narrow clones), but they generally aren't performance-related. I note that this is a good thing: Mercurial's repository structure allows it to do things that aren't easy for Git, especially efficient random access to history (Git's structures are generally optimized for access close to HEAD and the root of the directory tree), at the expense of requiring more disk space. The performance improvements you've seen most likely come from more/better caching or reimplementation of time-critical code. > fast branches without making a separate working directory for each That was always possible. Documentation (such as the Mercurial book) suggested a clone-based workflow for reasons of convenience and because that's what people were used to at the time, not because you had to do it this way.
    • krupan 11y ago
      Thank you for correcting. There is so much misinformation about mercurial out there.
• schodge 11y ago
  There was no version control on the transition? :)