7 ms·

The author states three reasons for switching. 1. Problems with storing big files in Mercurial. You can use the bigfiles extension if you really want to manage

by sreque 16y ago

The author states three reasons for switching. 1. Problems with storing big files in Mercurial. You can use the bigfiles extension if you really want to manage large files with Mercurial. 2. Inefficient renames. Making renames efficient is a currently recommended GSoC project. I'm sure this will be fixed eventually even if no one picks it up this summer. 3. Destructive commands actually, well, destroying stuff. This point makes me feel like the author knew git first, tried mercurial out, and switched back, making the blog post a little misleading. I don't know how you could expect a delete not to be a delete unless you were familiar with something like git already. If I were to run a delete command in Mercurial, I would read the documentation on the command first to make sure it created a backup for me. Only if it then failed to create this backup would I complain. Also, I think I prefer the bundle approach of Mercurial. You can always rename the bundles to keep track of them. You could even write your own extension in 5 lines that ran a destructive command and immediately unbundled the created bundle to restore your changesets, exactly duplicating git's functionality. The first two issues he mentions I would consider to be actually valid complaints against Mercurial, the third just a personal preference of the author. I would consider neither of them to be major game-changing issues.

pilif 16y ago
I don't know about Mercurial, but in your IDE / Editor, don't you like having multi-step undo no matter what command you execute? Or do you prefer to manually backup the files of your project before doing any operation in your editor that is potentially destroying your files? I'd much rather hit ctrl-z as many times as needed once I noticed my last refactoring has shredded all the files it touched. Being able to easily undo whatever I do to in whatever application I can think of is a nice feature - even more so if the application is what I entrust all my work to.
- sreque 16y ago
  When I run sed on a file, I don't expect it to make a backup copy of my file. Similarly, when I run rm, it doesn't create a backup of what I'm deleting. Destructive operations are, well, destructive! I'm amazed at the response I got to my post. Read the docs on a mercurial command. Chances are if it is destructive it creates a backup for you. On the off chance that someone writes an extension that fails to do so, you can create the backup yourself. There's nothing magic about git's operation here. Someone simply took the time to create a backup in git for a command for which the equivalent mercurial command didn't. Big deal.
  - joeyh 16y ago
    Git's repository structure, plus the built-in reflog prevents committed data being lost by any command, unless it explicitly erases the repository or reflog.
    - stonemetal 16y ago
      git stash drop git gc oopsie data loss. It is about what he did in hg, except in hg it is one command.
      - epall 16y ago
        The stash has its own reflog git gc only prunes nodes unreachable from branches AND the reflog, which I think by default is 30 days long
        joeyh 16y ago
        I explicitly said "committed data" would not be lost, because data only staged in the index certianly can be lost, and I think stashed data is also semi-suceptable to loss as well. git stash drop does print the sha1 of the stash, and as long as you know that sha1, and it's not been gc'd, you can get a dropped stash back. (git fsck will also show the sha1s of dangling commits left from dropped stashes.) But while a separate reflog records existing stashes, that information is not retained when they're dropped. It's perhaps best to think of git stash as a more convenient form of git diff > patch, and you wouldn't expect that to keep a log of the patch file either.
        stonemetal 16y ago
        Yes but the original author in this very thread has said that the data loss was through MQ(Mercurial patch Queue) delete. mercurial queues are an optionally controlled patch queue, so he had some code stashed it in an uncontrolled queue, deleted it and was surprised that it was really gone. This is rather analogous to what I posted for git. It was a bit of bad luck on his part but switching to git doesn't close that hole his code is still vulnerable to the same set of actions. So his whole reason for switching is I shot myself in the foot. And instead of learning more about his weapon of choice to avoid doing that in the future, he traded in his gun for one that is slightly more complicated.
randallsquared 16y ago
Destructive commands actually, well, destroying stuff. Part of the point of using a versioning system is to avoid ever destroying stuff. Therefore, in a versioning system, you'd expect to have to work pretty hard to make a change you couldn't roll back from, wouldn't you?
- sid0 16y ago
  Yes, and hg and git both make you work hard. I'm not sure what his point is. He used a quite advanced command without understanding its consequences, he paid the price. A non-advanced user would really have no need to use hg strip.
steveklabnik 16y ago
> I don't know how you could expect a delete not to be a delete unless you were familiar with something like git already. Because it's version control; isn't the whole point that I can change things and return to a previous state? I don't know anything about hg other than it being distributed, but if it destroys things, well, it's not a VCS as far as I'm concerned. That's crazy!
- dschobel 16y ago
  I'm not aware of any VCS which meets your standard of not allowing destructive commands (I'm sure you realize you can destroy history/data in git as well, right? It may take a --force, and it'll yell at you, but it's definitely doable)
  - steveklabnik 16y ago
    If I git rm something, and then git reset, my file is back. Are we talking about something different, or am I remembering git wrong? I don't actually git rm very often. And it makes sense that there's a permanent delete feature, but I'd expect it to be outside of the normal workflow.
    - sid0 16y ago
      Yes, hg has a non-destructive rm too. And yes, what he's talking about is outside the normal workflow. Way, way outside.
      - steveklabnik 16y ago
        Okay. Good. I thought it had to be that way. So why do you speculate he's using the wrong delete?
        sid0 16y ago
        Because he lost data? hg rm wouldn't ever lose data. He probably used an hg strip (which is an advanced command and must specifically be enabled in .hgrc through the mq extension) but didn't realize what he was doing...
vtail 16y ago
> I don't know how you could expect a delete not to be a delete unless you were familiar with something like git already. Ability to control and be able to reverse any changes you make to the source code tree is an essential feature of version control system - precisely because you don't know in advance what will work and what won't. The fact that people are not used to that simple idea just shows how broken are most of the other tools out there. There is no reason not to want an unlimited undo for almost everything, especially today when disk space is so cheap.
- DrJokepu 16y ago
  Maybe this is not that much relevant for DVCSs but in 'classic' VCSs such as SVN an 'obliterate' command would be quite useful, think about the case when someone accidentally commits something highly sensitive (such as private keys) to version control. People make mistakes all the time, either way.
  - charlesmarshall 16y ago
    you can use commands like git filter-branch & git rebase to change your history - http://www-cs-students.stanford.edu/~blynn/gitmagic/ch05.html http://www-cs-students.stanford.edu/~blynn/gitmagic/ch05.htm...
    - Xurinos 16y ago
      "git rebase" on its own does not permanently alter history. It creates a new branch that looks like a new history, but you can get back to the original history. "git gc" will prune the unused old histories for that permanent effect.
      - Vitaly 16y ago
        even "git gc" will not do it for a while. the old history will still be referenced from the reflog for some time (I think default is 30 days)
- 16y ago
technomancy 16y ago
> I don't know how you could expect a delete not to be a delete unless you were familiar with something like git already. Unless they were also familiar with functional programming and immutable data structures; it's the exact same mental model.

by sreque 16y ago

pilif 16y ago

I don't know about Mercurial, but in your IDE / Editor, don't you like having multi-step undo no matter what command you execute? Or do you prefer to manually backup the files of your project before doing any operation in your editor that is potentially destroying your files? I'd much rather hit ctrl-z as many times as needed once I noticed my last refactoring has shredded all the files it touched. Being able to easily undo whatever I do to in whatever application I can think of is a nice feature - even more so if the application is what I entrust all my work to.

sreque 16y ago
When I run sed on a file, I don't expect it to make a backup copy of my file. Similarly, when I run rm, it doesn't create a backup of what I'm deleting. Destructive operations are, well, destructive! I'm amazed at the response I got to my post. Read the docs on a mercurial command. Chances are if it is destructive it creates a backup for you. On the off chance that someone writes an extension that fails to do so, you can create the backup yourself. There's nothing magic about git's operation here. Someone simply took the time to create a backup in git for a command for which the equivalent mercurial command didn't. Big deal.
- joeyh 16y ago
  Git's repository structure, plus the built-in reflog prevents committed data being lost by any command, unless it explicitly erases the repository or reflog.
  - stonemetal 16y ago
    git stash drop git gc oopsie data loss. It is about what he did in hg, except in hg it is one command.
    - epall 16y ago
      The stash has its own reflog git gc only prunes nodes unreachable from branches AND the reflog, which I think by default is 30 days long
      - joeyh 16y ago
        I explicitly said "committed data" would not be lost, because data only staged in the index certianly can be lost, and I think stashed data is also semi-suceptable to loss as well. git stash drop does print the sha1 of the stash, and as long as you know that sha1, and it's not been gc'd, you can get a dropped stash back. (git fsck will also show the sha1s of dangling commits left from dropped stashes.) But while a separate reflog records existing stashes, that information is not retained when they're dropped. It's perhaps best to think of git stash as a more convenient form of git diff > patch, and you wouldn't expect that to keep a log of the patch file either.
        stonemetal 16y ago
        Yes but the original author in this very thread has said that the data loss was through MQ(Mercurial patch Queue) delete. mercurial queues are an optionally controlled patch queue, so he had some code stashed it in an uncontrolled queue, deleted it and was surprised that it was really gone. This is rather analogous to what I posted for git. It was a bit of bad luck on his part but switching to git doesn't close that hole his code is still vulnerable to the same set of actions. So his whole reason for switching is I shot myself in the foot. And instead of learning more about his weapon of choice to avoid doing that in the future, he traded in his gun for one that is slightly more complicated.

randallsquared 16y ago

Destructive commands actually, well, destroying stuff. Part of the point of using a versioning system is to avoid ever destroying stuff. Therefore, in a versioning system, you'd expect to have to work pretty hard to make a change you couldn't roll back from, wouldn't you?

sid0 16y ago
Yes, and hg and git both make you work hard. I'm not sure what his point is. He used a quite advanced command without understanding its consequences, he paid the price. A non-advanced user would really have no need to use hg strip.

steveklabnik 16y ago

> I don't know how you could expect a delete not to be a delete unless you were familiar with something like git already. Because it's version control; isn't the whole point that I can change things and return to a previous state? I don't know anything about hg other than it being distributed, but if it destroys things, well, it's not a VCS as far as I'm concerned. That's crazy!

dschobel 16y ago
I'm not aware of any VCS which meets your standard of not allowing destructive commands (I'm sure you realize you can destroy history/data in git as well, right? It may take a --force, and it'll yell at you, but it's definitely doable)
- steveklabnik 16y ago
  If I git rm something, and then git reset, my file is back. Are we talking about something different, or am I remembering git wrong? I don't actually git rm very often. And it makes sense that there's a permanent delete feature, but I'd expect it to be outside of the normal workflow.
  - sid0 16y ago
    Yes, hg has a non-destructive rm too. And yes, what he's talking about is outside the normal workflow. Way, way outside.
    - steveklabnik 16y ago
      Okay. Good. I thought it had to be that way. So why do you speculate he's using the wrong delete?
      - sid0 16y ago
        Because he lost data? hg rm wouldn't ever lose data. He probably used an hg strip (which is an advanced command and must specifically be enabled in .hgrc through the mq extension) but didn't realize what he was doing...

vtail 16y ago

> I don't know how you could expect a delete not to be a delete unless you were familiar with something like git already. Ability to control and be able to reverse any changes you make to the source code tree is an essential feature of version control system - precisely because you don't know in advance what will work and what won't. The fact that people are not used to that simple idea just shows how broken are most of the other tools out there. There is no reason not to want an unlimited undo for almost everything, especially today when disk space is so cheap.

DrJokepu 16y ago
Maybe this is not that much relevant for DVCSs but in 'classic' VCSs such as SVN an 'obliterate' command would be quite useful, think about the case when someone accidentally commits something highly sensitive (such as private keys) to version control. People make mistakes all the time, either way.
- charlesmarshall 16y ago
  you can use commands like git filter-branch & git rebase to change your history - http://www-cs-students.stanford.edu/~blynn/gitmagic/ch05.html http://www-cs-students.stanford.edu/~blynn/gitmagic/ch05.htm...
  - Xurinos 16y ago
    "git rebase" on its own does not permanently alter history. It creates a new branch that looks like a new history, but you can get back to the original history. "git gc" will prune the unused old histories for that permanent effect.
    - Vitaly 16y ago
      even "git gc" will not do it for a while. the old history will still be referenced from the reflog for some time (I think default is 30 days)
16y ago

technomancy 16y ago

> I don't know how you could expect a delete not to be a delete unless you were familiar with something like git already. Unless they were also familiar with functional programming and immutable data structures; it's the exact same mental model.