5 ms·

I think Mercurial is way ahead of Git on this department by having repositories immutable by default, so even undo actions would have their commit. You never fi

by sedatk 5y ago

I think Mercurial is way ahead of Git on this department by having repositories immutable by default, so even undo actions would have their commit. You never find yourself in an unrecoverable situation. Advanced mutable features can only be accessed by making configuration changes, and are still safe to use because public changesets are differentiated from draft changesets, so, you can only make changes on your own work, not anything else. I mean, you can force it, but that comes with its warnings. Mercurial has no staging area, and that can be inconvenient for some scenarios; but I think no-staging model is easier to grasp for beginners. I especially think many beginners would assume that modifying a file after it's been added to staging area would update staging area automatically too. Mercurial has high-level, scenario-oriented distinct "undo" commands like "revert", "forget" and "backout" instead of overloading a single command ("reset") for everything. I still like `git reflog` though.

umvi 5y ago
Sounds like mercurial repos would have a lot of "noise" with that approach - commits for fixing other commits spamming everywhere
- capitainenemo 5y ago
  https://www.mercurial-scm.org/doc/evolution/user-guide.html#changeset-obsolescence-under-the-hood https://www.mercurial-scm.org/doc/evolution/user-guide.html#... The key thing seems to be the immutable repo editing is hidden by default, but viewable with --hidden flag if you need it.
- sedatk 5y ago
  Eh, some may call it noise, some may call it "thank God my work is saved!". That only applies to pushed changesets btw, may I remind you. You can obviously remove/restructure local commits as you like; you just need to enable certain extensions for mutability.
- globular-toast 5y ago
  Git does too. It's garbage collected after 90 days or so. It doesn't amount to as much as you might think due to Git's data model.
globular-toast 5y ago
Git is immutable. The only thing that isn't is your working directory.
- sedatk 5y ago
  How do people lose their work so easily with Git then?
  - meowface 5y ago
    Because, as the parent poster said, everything is immutable except the working directory. The working directory is the default place where all the work is done, as the name suggests. You have to explicitly move things from the working directory to the other areas in order for git to recognize it; the default is "do nothing". On top of this, various git commands can delete things you've done in the working directory without any confirmation or warning (e.g. "git checkout [filename]"). And of course, so can various non-git commands (e.g. "rm [filename]"). If that happens, the work is permanently lost if there isn't another backup mechanism in place. So they're not wrong, but the second sentence's implications are kind of glossed over. It's always confused me that git lets you lose work so easily, so a very long time ago I've always just made sure to put all of my programming projects in a Dropbox folder. I rarely mess anything up that badly with git, but for the few times I have, Dropbox version history has definitely saved me.
    - cmeacham98 5y ago
      They are wrong, there are actions you can take in git that will cause you to lose your "immutable" history. Most accidental cases probably involve `git reset` or `git rebase`, but here's an example if you want to do it intentionally: # Commit all changes and push to at least one remote so your changes are ""immutable"" rm -rf myrepo/ mkdir example && cd example git init # Repeat for each remote git remote add remote1 https://origin.for/your/repo git push remote1 --mirror --force Congrats, you've lost everything! (Except for your backups, you do have backups right?)

by sedatk 5y ago

umvi 5y ago

Sounds like mercurial repos would have a lot of "noise" with that approach - commits for fixing other commits spamming everywhere

capitainenemo 5y ago
https://www.mercurial-scm.org/doc/evolution/user-guide.html#changeset-obsolescence-under-the-hood https://www.mercurial-scm.org/doc/evolution/user-guide.html#... The key thing seems to be the immutable repo editing is hidden by default, but viewable with --hidden flag if you need it.
sedatk 5y ago
Eh, some may call it noise, some may call it "thank God my work is saved!". That only applies to pushed changesets btw, may I remind you. You can obviously remove/restructure local commits as you like; you just need to enable certain extensions for mutability.
globular-toast 5y ago
Git does too. It's garbage collected after 90 days or so. It doesn't amount to as much as you might think due to Git's data model.

globular-toast 5y ago

Git is immutable. The only thing that isn't is your working directory.

sedatk 5y ago
How do people lose their work so easily with Git then?
- meowface 5y ago
  Because, as the parent poster said, everything is immutable except the working directory. The working directory is the default place where all the work is done, as the name suggests. You have to explicitly move things from the working directory to the other areas in order for git to recognize it; the default is "do nothing". On top of this, various git commands can delete things you've done in the working directory without any confirmation or warning (e.g. "git checkout [filename]"). And of course, so can various non-git commands (e.g. "rm [filename]"). If that happens, the work is permanently lost if there isn't another backup mechanism in place. So they're not wrong, but the second sentence's implications are kind of glossed over. It's always confused me that git lets you lose work so easily, so a very long time ago I've always just made sure to put all of my programming projects in a Dropbox folder. I rarely mess anything up that badly with git, but for the few times I have, Dropbox version history has definitely saved me.
  - cmeacham98 5y ago
    They are wrong, there are actions you can take in git that will cause you to lose your "immutable" history. Most accidental cases probably involve `git reset` or `git rebase`, but here's an example if you want to do it intentionally: # Commit all changes and push to at least one remote so your changes are ""immutable"" rm -rf myrepo/ mkdir example && cd example git init # Repeat for each remote git remote add remote1 https://origin.for/your/repo git push remote1 --mirror --force Congrats, you've lost everything! (Except for your backups, you do have backups right?)