5 ms·

Hg and Git : Can't we all just get along? (PyCon Presentation)

25 points by mace 17y ago

sumeeta 17y ago
”Salt Lake City merges.” Merges with more than one parent.
- eru 17y ago
  Shouldn't this be "wholesome family merges", unless the number of parents exceeds two?
- schacon 17y ago
  To be pedantically accurate, it's merges with more than two parents.
njl 17y ago
I view any sort of advocacy of git over hg or hg over git as borderline ridiculous. Any differentiation between the two is so far out in the margins as to be irrelevant.
- dschobel 17y ago
  Why? They have substantial differences. Beyond the fundamental data model (DAG for git vs change-sets for hg) they have significant usability differences. The most obvious of those is the git concept of manually staging commits. That's a core design decision which you interact with on virtually every git operation (and no, DirState does not compare). Think of it by analogy to python vs ruby. They both do the same thing and are used in the very similar problem spaces, but that does not make them similar technologies nor does it mean proficiency in one is transferable to the other.
  - brodie 17y ago
    I agree with you that the two projects have different philosophies on version control, but I'd like to offer some corrections: 1. Both Mercurial and Git use the same history model; both have DAGs and changesets. 2. The dirstate is an internal format, and it's analogous to Git's index. You are right though, that Git allows you to manage it manually is a big difference from Mercurial. I think Mercurial tends to be more conservative in what it allows; it discourages history editing, and it tries to be similar to Subversion and CVS in terms of UI. Git, on the other hand, provides all the power user features - like commit amendment, rebasing, and index management - up front.
    - driax 17y ago
      While I agree Mercurial generally is more conservative I also believe they do this because they have a well used extension system. So you can't really say they don't support power user features when many of them are only a configuration option away. The real difference I thing is the way they manage branches, because this is part of the repository itself, thus changing it through extensions requires everybody that pulls the repository also install this extension. And if you do this then you aren't really using Mercurial or Git, you have instead created your own DVCS.
  - ubernostrum 17y ago
    To go with your analogy, I think the point would be that it's silly to argue one of (Python/Ruby) is objectively superior to the other. Yet with version-control that's precisely the argument we hear so often; yes, the workflows are different, and the particular techniques for specific use cases are different, but there aren't -- so far as I know -- many, if any, use cases where one or the other just falls over and says "that's impossible".

25 points by mace 17y ago

sumeeta 17y ago

”Salt Lake City merges.” Merges with more than one parent.

eru 17y ago
Shouldn't this be "wholesome family merges", unless the number of parents exceeds two?
schacon 17y ago
To be pedantically accurate, it's merges with more than two parents.

njl 17y ago

I view any sort of advocacy of git over hg or hg over git as borderline ridiculous. Any differentiation between the two is so far out in the margins as to be irrelevant.

dschobel 17y ago
Why? They have substantial differences. Beyond the fundamental data model (DAG for git vs change-sets for hg) they have significant usability differences. The most obvious of those is the git concept of manually staging commits. That's a core design decision which you interact with on virtually every git operation (and no, DirState does not compare). Think of it by analogy to python vs ruby. They both do the same thing and are used in the very similar problem spaces, but that does not make them similar technologies nor does it mean proficiency in one is transferable to the other.
- brodie 17y ago
  I agree with you that the two projects have different philosophies on version control, but I'd like to offer some corrections: 1. Both Mercurial and Git use the same history model; both have DAGs and changesets. 2. The dirstate is an internal format, and it's analogous to Git's index. You are right though, that Git allows you to manage it manually is a big difference from Mercurial. I think Mercurial tends to be more conservative in what it allows; it discourages history editing, and it tries to be similar to Subversion and CVS in terms of UI. Git, on the other hand, provides all the power user features - like commit amendment, rebasing, and index management - up front.
  - driax 17y ago
    While I agree Mercurial generally is more conservative I also believe they do this because they have a well used extension system. So you can't really say they don't support power user features when many of them are only a configuration option away. The real difference I thing is the way they manage branches, because this is part of the repository itself, thus changing it through extensions requires everybody that pulls the repository also install this extension. And if you do this then you aren't really using Mercurial or Git, you have instead created your own DVCS.
- ubernostrum 17y ago
  To go with your analogy, I think the point would be that it's silly to argue one of (Python/Ruby) is objectively superior to the other. Yet with version-control that's precisely the argument we hear so often; yes, the workflows are different, and the particular techniques for specific use cases are different, but there aren't -- so far as I know -- many, if any, use cases where one or the other just falls over and says "that's impossible".