6 ms·

> 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

by 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.
  - dvdgsng 11y ago
    won what?
    - acveilleux 11y ago
      It has won GitHub, that's mostly it. Separately, GitHub has won the "place where you share you project code" prize that used to belong to sourceforge.
  - theandrewbailey 11y ago
    You haven't mentioned why you think Git won. If by "won", you mean "is more popular", then yes, it won. But that criteria alone doesn't make a decision bad. When changing gives you no clear advantage, why change to something more popular?
    - lsaferite 11y ago
      Isn't that akin to arguing that choosing to distribute your movies only on Betamax is not a bad decision?
- jgraham 11y ago
  Well arguably the long-term result for Mozilla is that we have ended up having to support two version control systems for everything because there has been less resistance to that than trying to force people to use mercurial for everything (for the projects that were already in mercurial people wrote git bridges, and for new projects people tended to start them on GitHub). I strongly doubt that there would have been the same problem if we had used git from the start. I suspect this is a net negative, even if you believe the rhetoric that mercurial (or future-mercurial) has technical advantages in some areas. Edit: to be clear, the kind of "everything" I have in mind is the code review system which now has to support two version control tools. Indeed if we'd used git from the start there might well have been an off-the-shelf code review tool we could have used without putting multiple man years of effort into customisations.
koenigdavidmj 11y ago
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.
- masklinn 11y ago
  > 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.
  - glandium 11y ago
    > but fundamentally you're still installing msys (2) to run git. You're installing msys to run git because (I guess) it was considered the git CLI would be useless without a decent shell. Would you see yourself use Git or Mercurial in cmd? Git itself in Git for Windows, afaik, is not actually an msys program, and uses native win32 APIs.
    - TylerE 11y ago
      Ever heard of a thing called powershell?
      - cyphar 11y ago
        Is that like Bash for Kids?
        koenigdavidmj 11y ago
tzs 11y ago
> Ouch, yet another way in which running on Windows can lead to poor technical decisions. Are you implying that choosing hg was a poor technical decision? Or are you just making the general observation that if you include non-technical requirements when choosing a tool (and if we accept that running on a specific set of platforms is not a technical requirement...) then you might not end up with the choice that would have been best if all the requirements were purely technical? If the former, then you should elaborate. As far as I was able to determine when I evaluated both hg and git is that they are essentially equivalent technically. Git's default interface makes some things visible that hg keeps behind the scenes, but these are all a quick hg extension installation away for those who want them.
- JoshTriplett 11y ago
  > As far as I was able to determine when I evaluated both hg and git is that they are essentially equivalent technically. Today, yes. Significant work went into getting Mercurial's internals up to parity with Git's, and conversely into getting Git's UI up to parity with Mercurial's.
  - carussell 11y ago
    Respectfully, Git still has a long way to go before it achieves parity with Mercurial, or even its state of the art from, say, 2010. Don't discount the effect that familiarity with a tool or process can have on your perception of it. The most succinct explanation of this effect that I know comes from the title of a post on the Light Table blog called, "Pain We Forgot". Coming from a Mozilla-influenced, pre-GitHub-explosion background, I'm one of those people always favored Mercurial but used both out of necessity. Mostly that meant using hg for my own stuff that is most likely never to see the light of day and git for almost everything else. But I also ended up calling it quits on Mercurial and pulled the trigger on git-for-everything last week. So, having just written (what should be a completely unnecessary) tool to dump out stats about files' line ending conventions, again, I'll say that Git has a long way to go. (And before you ask, yes the problem manifests itself using the latest version of Git, and there's nothing exotic or wacky to my workflow, nor am I witnessing the effect of interplay with other tools of dubious quality. This is an outright case of Git's tendency to drop the ball and then gesture in the vague direction of a poorly documented non-fix that cuts orthogonally to the problem it's supposed to be solving.)
jcranmer 11y ago
It's worth pointing out that part of the reason that Mozilla selected Mercurial over Git was that the Mercurial developers were more willing to help fix issues that Mozilla had identified than Git was, with Windows support being the most important point. 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.
- __david__ 11y ago
  > 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™ Wow, I can't disagree with that notion more. I've been on many projects that use git and practically every one used git in different ways. I've never felt that git was trying to force a particular workflow on me. Git's greatest strength, to me, has always been its toolbox nature—you can make it do whatever you like (want to comb through your entire repo and change someone's email address, or backdate an entire branch? No problem!).
- glandium 11y ago
  > 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™ Considering the number of tools based on the Git data model to do completely unrelated things (I'm thinking about e.g. bup or git-annex). I wouldn't say that's Git imposes you a One True Model. Also, Git doesn't restrict you to an arbitrary number of parents on a commit ;). BTW, > The Mercurial community seems to be working hard on making enormous monolithic repositories much more performant and realiable The irony is that to do so, Mercurial had to bend its data model, adding (backwards incompatible) support for per-directory manifests (which sound a lot like trees in Git, except the part where manifests have history attached to them, where Git only has history attached to commits).

by zeveb 11y ago

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.
- dvdgsng 11y ago
  won what?
  - acveilleux 11y ago
    It has won GitHub, that's mostly it. Separately, GitHub has won the "place where you share you project code" prize that used to belong to sourceforge.
- theandrewbailey 11y ago
  You haven't mentioned why you think Git won. If by "won", you mean "is more popular", then yes, it won. But that criteria alone doesn't make a decision bad. When changing gives you no clear advantage, why change to something more popular?
  - lsaferite 11y ago
    Isn't that akin to arguing that choosing to distribute your movies only on Betamax is not a bad decision?
jgraham 11y ago
Well arguably the long-term result for Mozilla is that we have ended up having to support two version control systems for everything because there has been less resistance to that than trying to force people to use mercurial for everything (for the projects that were already in mercurial people wrote git bridges, and for new projects people tended to start them on GitHub). I strongly doubt that there would have been the same problem if we had used git from the start. I suspect this is a net negative, even if you believe the rhetoric that mercurial (or future-mercurial) has technical advantages in some areas. Edit: to be clear, the kind of "everything" I have in mind is the code review system which now has to support two version control tools. Indeed if we'd used git from the start there might well have been an off-the-shelf code review tool we could have used without putting multiple man years of effort into customisations.

koenigdavidmj 11y ago

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.

masklinn 11y ago
> 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.
- glandium 11y ago
  > but fundamentally you're still installing msys (2) to run git. You're installing msys to run git because (I guess) it was considered the git CLI would be useless without a decent shell. Would you see yourself use Git or Mercurial in cmd? Git itself in Git for Windows, afaik, is not actually an msys program, and uses native win32 APIs.
  - TylerE 11y ago
    Ever heard of a thing called powershell?
    - cyphar 11y ago
      Is that like Bash for Kids?
      - koenigdavidmj 11y ago

tzs 11y ago

> Ouch, yet another way in which running on Windows can lead to poor technical decisions. Are you implying that choosing hg was a poor technical decision? Or are you just making the general observation that if you include non-technical requirements when choosing a tool (and if we accept that running on a specific set of platforms is not a technical requirement...) then you might not end up with the choice that would have been best if all the requirements were purely technical? If the former, then you should elaborate. As far as I was able to determine when I evaluated both hg and git is that they are essentially equivalent technically. Git's default interface makes some things visible that hg keeps behind the scenes, but these are all a quick hg extension installation away for those who want them.

JoshTriplett 11y ago
> As far as I was able to determine when I evaluated both hg and git is that they are essentially equivalent technically. Today, yes. Significant work went into getting Mercurial's internals up to parity with Git's, and conversely into getting Git's UI up to parity with Mercurial's.
- carussell 11y ago
  Respectfully, Git still has a long way to go before it achieves parity with Mercurial, or even its state of the art from, say, 2010. Don't discount the effect that familiarity with a tool or process can have on your perception of it. The most succinct explanation of this effect that I know comes from the title of a post on the Light Table blog called, "Pain We Forgot". Coming from a Mozilla-influenced, pre-GitHub-explosion background, I'm one of those people always favored Mercurial but used both out of necessity. Mostly that meant using hg for my own stuff that is most likely never to see the light of day and git for almost everything else. But I also ended up calling it quits on Mercurial and pulled the trigger on git-for-everything last week. So, having just written (what should be a completely unnecessary) tool to dump out stats about files' line ending conventions, again, I'll say that Git has a long way to go. (And before you ask, yes the problem manifests itself using the latest version of Git, and there's nothing exotic or wacky to my workflow, nor am I witnessing the effect of interplay with other tools of dubious quality. This is an outright case of Git's tendency to drop the ball and then gesture in the vague direction of a poorly documented non-fix that cuts orthogonally to the problem it's supposed to be solving.)

jcranmer 11y ago

It's worth pointing out that part of the reason that Mozilla selected Mercurial over Git was that the Mercurial developers were more willing to help fix issues that Mozilla had identified than Git was, with Windows support being the most important point. 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.

__david__ 11y ago
> 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™ Wow, I can't disagree with that notion more. I've been on many projects that use git and practically every one used git in different ways. I've never felt that git was trying to force a particular workflow on me. Git's greatest strength, to me, has always been its toolbox nature—you can make it do whatever you like (want to comb through your entire repo and change someone's email address, or backdate an entire branch? No problem!).
glandium 11y ago
> 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™ Considering the number of tools based on the Git data model to do completely unrelated things (I'm thinking about e.g. bup or git-annex). I wouldn't say that's Git imposes you a One True Model. Also, Git doesn't restrict you to an arbitrary number of parents on a commit ;). BTW, > The Mercurial community seems to be working hard on making enormous monolithic repositories much more performant and realiable The irony is that to do so, Mercurial had to bend its data model, adding (backwards incompatible) support for per-directory manifests (which sound a lot like trees in Git, except the part where manifests have history attached to them, where Git only has history attached to commits).