4 ms·

Writing the basics of a DVCS in two weeks isn't a unique feat. Mercurial was created in almost exactly the same way, and was faster than git (and still is, e.g.

by jordigh 13y ago

Writing the basics of a DVCS in two weeks isn't a unique feat. Mercurial was created in almost exactly the same way, and was faster than git (and still is, e.g. for blame and clone operations) and actually was conceived with a UI from the beginning. I'm pretty sure the only reason git took most of the mind share instead of hg was (1) github (2) Linus admiration.

codemac 13y ago
Well, you're also missing some reasons: - git has an 'email' centric workflow - The index with git (git add -i) awesome for people doing patch maintenance - the rebase workflow is great when you want to maintain against an upstream that you expect someone other than you to commit your changes to, or you have a "pre-publish" phase. It's almost like those reasons follow the linux workflow.. almost perfectly.
- zurn 13y ago
  Those aren't big things outside Linux.
  - throwaway7767 13y ago
    Email centric workflows are used for lots of projects other than the linux kernel. My workflow for a lot of the projects I contribute to is something like: edit -> commit (repeat as necessary) -> rebase -i -> format-patch -> send patchset by email
- Argorak 13y ago
  > - git has an 'email' centric workflow Which is surprising, given how rough all the email-involving commands of git are. Badly documented (git-send-email man page doesn't even come close to documenting all options properly), awful error reporting and a badly explained (although, in itself, quite sane) workflow when sending the patches. When setting up my email setup, I consulted the underlying Perl script more than the docs :(.
- read 13y ago
  - git has an 'email' centric workflow That's a good observation. Git seems to assume its distributed issue-tracker is email.
- jordigh 13y ago
  Sigh, I wish people would actually know about Mercurial. It was created for the exact same reason as git, at the same time, and is also intended for kernel development. In particular, - Mercurial also has an email-centric workflow, look at its mailing list: http://mercurial.markmail.org/search/?q=#query:+page:1+mid:pwzmpl2ii2hgod4v+state:results http://mercurial.markmail.org/search/?q=#query:+page:1+mid:p... - The staging area can be achieved in hg in several ways, or it can be avoided as desired. One easy way is to just pick apart your commit with hg (c)record --amend and just keep adding to your commit as necessary. - Rebasing has also been available in hg forever (and wasn't available in git from the beginning). We also have some really interesting changes brewing for rebasing in Mercurial: https://www.youtube.com/watch?v=4OlDm3akbqg https://www.youtube.com/watch?v=4OlDm3akbqg These ideas in hg were all for following the Linux workflow too. Nothing against git, but it's important to not deify Linus as if he were a unique genius. He has his flaws, and so does the software that he's responsible for.
  - dredmorbius 13y ago
    I've used both. Mercurial beat git past the starting gates, but git has the advantage of being used on a very widely used, widely developed, immensely high profile project. While Hg has its own commendable set of projects, git has simply won the mindshare battle. Could be worse: there's arch and bzr and probably some others. Hell, even GNU/EFF are looking to ditch their own VCS in favor of git from what I understand.
    - jordigh 13y ago
      Yes, that's true git's main advantage is how widespread it is. GNU Emacs decided to switch from bzr to git, but GNU as a whole doesn't have a recommended VCS yet. In GNU Octave we will keep using hg. I don't think the EFF is too public about which VCS they use.
      - dredmorbius 13y ago
        I meant to type "GNU/FSF". I thought I caught myself and corrected the "EFF" bit. I knew I was going to write that. And damnit, I did. But yes, I meant "FSF", not "EFF".
stiff 13y ago
Every occasion is good to start a flame war, isn't it?
- deleted 13y ago
  [deleted]
huhtenberg 13y ago
(3) C implementation There's a strong aversion of using tools done in Python outside of Python community. It is irrational, but it being an inherently interpreted language puts it into the same perception bucket as Perl and who'd want to use a control system written in Perl?
- dima55 13y ago
  Dude, python IS in the same bucket as perl. The list of pros and cons when compared to C is identical.
  - huhtenberg 13y ago
    Shhh... don't tell HN.
  - annnnd 13y ago
    There is one difference - you need an external tool to properly obfuscate Python source code. :)

by jordigh 13y ago

codemac 13y ago

Well, you're also missing some reasons: - git has an 'email' centric workflow - The index with git (git add -i) awesome for people doing patch maintenance - the rebase workflow is great when you want to maintain against an upstream that you expect someone other than you to commit your changes to, or you have a "pre-publish" phase. It's almost like those reasons follow the linux workflow.. almost perfectly.

zurn 13y ago
Those aren't big things outside Linux.
- throwaway7767 13y ago
  Email centric workflows are used for lots of projects other than the linux kernel. My workflow for a lot of the projects I contribute to is something like: edit -> commit (repeat as necessary) -> rebase -i -> format-patch -> send patchset by email
Argorak 13y ago
> - git has an 'email' centric workflow Which is surprising, given how rough all the email-involving commands of git are. Badly documented (git-send-email man page doesn't even come close to documenting all options properly), awful error reporting and a badly explained (although, in itself, quite sane) workflow when sending the patches. When setting up my email setup, I consulted the underlying Perl script more than the docs :(.
read 13y ago
- git has an 'email' centric workflow That's a good observation. Git seems to assume its distributed issue-tracker is email.
jordigh 13y ago
Sigh, I wish people would actually know about Mercurial. It was created for the exact same reason as git, at the same time, and is also intended for kernel development. In particular, - Mercurial also has an email-centric workflow, look at its mailing list: http://mercurial.markmail.org/search/?q=#query:+page:1+mid:pwzmpl2ii2hgod4v+state:results http://mercurial.markmail.org/search/?q=#query:+page:1+mid:p... - The staging area can be achieved in hg in several ways, or it can be avoided as desired. One easy way is to just pick apart your commit with hg (c)record --amend and just keep adding to your commit as necessary. - Rebasing has also been available in hg forever (and wasn't available in git from the beginning). We also have some really interesting changes brewing for rebasing in Mercurial: https://www.youtube.com/watch?v=4OlDm3akbqg https://www.youtube.com/watch?v=4OlDm3akbqg These ideas in hg were all for following the Linux workflow too. Nothing against git, but it's important to not deify Linus as if he were a unique genius. He has his flaws, and so does the software that he's responsible for.
- dredmorbius 13y ago
  I've used both. Mercurial beat git past the starting gates, but git has the advantage of being used on a very widely used, widely developed, immensely high profile project. While Hg has its own commendable set of projects, git has simply won the mindshare battle. Could be worse: there's arch and bzr and probably some others. Hell, even GNU/EFF are looking to ditch their own VCS in favor of git from what I understand.
  - jordigh 13y ago
    Yes, that's true git's main advantage is how widespread it is. GNU Emacs decided to switch from bzr to git, but GNU as a whole doesn't have a recommended VCS yet. In GNU Octave we will keep using hg. I don't think the EFF is too public about which VCS they use.
    - dredmorbius 13y ago
      I meant to type "GNU/FSF". I thought I caught myself and corrected the "EFF" bit. I knew I was going to write that. And damnit, I did. But yes, I meant "FSF", not "EFF".

stiff 13y ago

Every occasion is good to start a flame war, isn't it?

deleted 13y ago
[deleted]

huhtenberg 13y ago

(3) C implementation There's a strong aversion of using tools done in Python outside of Python community. It is irrational, but it being an inherently interpreted language puts it into the same perception bucket as Perl and who'd want to use a control system written in Perl?

dima55 13y ago
Dude, python IS in the same bucket as perl. The list of pros and cons when compared to C is identical.
- huhtenberg 13y ago
  Shhh... don't tell HN.
- annnnd 13y ago
  There is one difference - you need an external tool to properly obfuscate Python source code. :)