6 ms·

I started version control with CVS. Just a bit better than copying. I started distributed version control with monotone. That felt better but the central db fe

by lixtra 8y ago

I started version control with CVS. Just a bit better than copying. I started distributed version control with monotone. That felt better but the central db felt a bit unnatural. A bit later came mercurial and I was really happy with it. It all made sense. Easy interface and when you wanted to do something strange like rewrite history, you had to use a plugin. Then came git (rhymes to better know your sh*t). I'm not surrounded by the smartest guys but most people I met only have a superficial understanding of git and looking at these flight rules kind of confirms the complexity of git. I strongly believe that 80% of the current users of git would be better off with mercurial. But then everybody uses git for the remaining 20%.

pavel_lishin 8y ago
Mercurial doesn't have branches, right? That drove me bonkers when I was doing a bit of contract work after having used git for awhile. edit: They must have been using a different SCM; ignore me!
- jfk13 8y ago
  https://www.mercurial-scm.org/wiki/Branch https://www.mercurial-scm.org/wiki/Branch Perhaps you're thinking of a different meaning of "branch"?
  - pavel_lishin 8y ago
    I must be thinking of a different SVN.
    - tome 8y ago
      You must be thinking of a different TLA.
      - pavel_lishin 8y ago
        I am not having a good brain day today :P
- deleted 8y ago
  [deleted]
- BeetleB 8y ago
  They have had branches, at least since I started using hg (2010). But no one uses them. Everyone uses bookmarks as branches.
- BerislavLopac 8y ago
  Not only that it has branches -- it has four different ways to branch. http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
  - masklinn 8y ago
    Of note: Git has 3 of those: * git has clones * git has bookmarks, that's "normal" git branches * git has anonymous branches, it's called "detached head" and is completely broken * git does not have named branches (that's the branch name being part of the commit's immutable metadata)
    - dtech 8y ago
      > the branch name being part of the commit's immutable metadata To a git user, what's the rationale and when is this useful?
      - lixtra 8y ago
        When you want to know were some commit came from. For example you can make a seemingly unrelated change in a feature branch. And then later wonder why this change has been done. Of course you could hope to find the merge into master where the feature name could be mentioned. But it’s nicer to have it on the commit. => it gives extra context to the commit
    - BerislavLopac 8y ago
      Well, considering one is broken I would still argue that it has two, just as the article states. Not that it needs much more -- git branching works perfectly fine. That said, I'm somewhat disappointed that cloning has fallen out of favour and it's standard to use an upstream server (usually GitHub) not only as a central authority but also as intermediary for sharing code. Apart from "forking", cloning repos has practically been delegated to history.
    - krupan 8y ago
      I've seen plenty of git users put "[JIRA-1234]" at the beginning of a string of commit messages. That's basically poor-man's mercurial named branches.
BeetleB 8y ago
>I strongly believe that 80% of the current users of git would be better off with mercurial. I concur. I was in a team that needed to migrate away from SVN. I was already privately using mercurial while in the team. Jumping to git was too much for them in complexity. I tried convincing them that mercurial will give them almost all the benefits without the (needless) complexity, but they wouldn't listen and ended up using TFS.
XCabbage 8y ago
Asking as someone who's never touched Mercurial: how is Mercurial simpler? Looking at https://confluence.atlassian.com/get-started-with-bitbucket/git-and-mercurial-commands-860009656.html https://confluence.atlassian.com/get-started-with-bitbucket/..., the conceptual model looks almost identical, and so do the commands for common tasks.
- lixtra 8y ago
  git has 3+1 areas where a change can live: - working directory - staged - commited - (upstream) * hg has only 2+1 - working directory - commited - (upstream) * (*) both support something like stash but in hg it is easier to avoid that. git log shows you history depending on the checked out version hg log shows you the whole history of the branch, also after your checked out version. Knowing where you are is very valuable. in hg you can push multiple heads into a repo. that is very convenient when a junior is unable to merge something. to my understanding in git you need different branches. git - linus wants you to edit commits until they are perfect hg - mpm once said that you have to accpet mistakes that happen[1] as a consequence git has more advanced features very exposed while hg has a simple novice workflow [1] https://www.mercurial-scm.org/pipermail/mercurial/2006-June/008751.html https://www.mercurial-scm.org/pipermail/mercurial/2006-June/...
  - nemetroid 8y ago
    > (*) both support something like stash but in hg it is easier to avoid that. Incidentally, using shelve in hg is the only way I've ever lost work in a VCS (I've made the same error in git as well, but a dropped stash can be found again). > git log shows you history depending on the checked out version > hg log shows you the whole history of the branch, also after your checked out version. Knowing where you are is very valuable. git can show this, too, if you ask for it. If you've checked out some ancestor of `branch-name`, then `git log branch-name` will show `HEAD` next to the commit you've checked out. A single commit can belong to multiple branches, so if git showed you commits after your checked out version, which branch should it show? All of them? > git - linus wants you to edit commits until they are perfect You can use a never-rebase workflow in git as well, but most people elect not to.

by lixtra 8y ago

pavel_lishin 8y ago

Mercurial doesn't have branches, right? That drove me bonkers when I was doing a bit of contract work after having used git for awhile. edit: They must have been using a different SCM; ignore me!

jfk13 8y ago
https://www.mercurial-scm.org/wiki/Branch https://www.mercurial-scm.org/wiki/Branch Perhaps you're thinking of a different meaning of "branch"?
- pavel_lishin 8y ago
  I must be thinking of a different SVN.
  - tome 8y ago
    You must be thinking of a different TLA.
    - pavel_lishin 8y ago
      I am not having a good brain day today :P
deleted 8y ago
[deleted]
BeetleB 8y ago
They have had branches, at least since I started using hg (2010). But no one uses them. Everyone uses bookmarks as branches.
BerislavLopac 8y ago
Not only that it has branches -- it has four different ways to branch. http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
- masklinn 8y ago
  Of note: Git has 3 of those: * git has clones * git has bookmarks, that's "normal" git branches * git has anonymous branches, it's called "detached head" and is completely broken * git does not have named branches (that's the branch name being part of the commit's immutable metadata)
  - dtech 8y ago
    > the branch name being part of the commit's immutable metadata To a git user, what's the rationale and when is this useful?
    - lixtra 8y ago
      When you want to know were some commit came from. For example you can make a seemingly unrelated change in a feature branch. And then later wonder why this change has been done. Of course you could hope to find the merge into master where the feature name could be mentioned. But it’s nicer to have it on the commit. => it gives extra context to the commit
  - BerislavLopac 8y ago
    Well, considering one is broken I would still argue that it has two, just as the article states. Not that it needs much more -- git branching works perfectly fine. That said, I'm somewhat disappointed that cloning has fallen out of favour and it's standard to use an upstream server (usually GitHub) not only as a central authority but also as intermediary for sharing code. Apart from "forking", cloning repos has practically been delegated to history.
  - krupan 8y ago
    I've seen plenty of git users put "[JIRA-1234]" at the beginning of a string of commit messages. That's basically poor-man's mercurial named branches.

BeetleB 8y ago

>I strongly believe that 80% of the current users of git would be better off with mercurial. I concur. I was in a team that needed to migrate away from SVN. I was already privately using mercurial while in the team. Jumping to git was too much for them in complexity. I tried convincing them that mercurial will give them almost all the benefits without the (needless) complexity, but they wouldn't listen and ended up using TFS.

XCabbage 8y ago

Asking as someone who's never touched Mercurial: how is Mercurial simpler? Looking at https://confluence.atlassian.com/get-started-with-bitbucket/git-and-mercurial-commands-860009656.html https://confluence.atlassian.com/get-started-with-bitbucket/..., the conceptual model looks almost identical, and so do the commands for common tasks.

lixtra 8y ago
git has 3+1 areas where a change can live: - working directory - staged - commited - (upstream) * hg has only 2+1 - working directory - commited - (upstream) * (*) both support something like stash but in hg it is easier to avoid that. git log shows you history depending on the checked out version hg log shows you the whole history of the branch, also after your checked out version. Knowing where you are is very valuable. in hg you can push multiple heads into a repo. that is very convenient when a junior is unable to merge something. to my understanding in git you need different branches. git - linus wants you to edit commits until they are perfect hg - mpm once said that you have to accpet mistakes that happen[1] as a consequence git has more advanced features very exposed while hg has a simple novice workflow [1] https://www.mercurial-scm.org/pipermail/mercurial/2006-June/008751.html https://www.mercurial-scm.org/pipermail/mercurial/2006-June/...
- nemetroid 8y ago
  > (*) both support something like stash but in hg it is easier to avoid that. Incidentally, using shelve in hg is the only way I've ever lost work in a VCS (I've made the same error in git as well, but a dropped stash can be found again). > git log shows you history depending on the checked out version > hg log shows you the whole history of the branch, also after your checked out version. Knowing where you are is very valuable. git can show this, too, if you ask for it. If you've checked out some ancestor of `branch-name`, then `git log branch-name` will show `HEAD` next to the commit you've checked out. A single commit can belong to multiple branches, so if git showed you commits after your checked out version, which branch should it show? All of them? > git - linus wants you to edit commits until they are perfect You can use a never-rebase workflow in git as well, but most people elect not to.