4 ms·

I can't count the number of times I've googled for simple commands like "how do I revert an uncommited file to its original state"? hg revert bla.txt g

by pka 14y ago

I can't count the number of times I've googled for simple commands like "how do I revert an uncommited file to its original state"? hg revert bla.txt git ??? ... and I would still have to google for it (it's something with HEAD iirc). Its usability is atrociously bad and I don't want to spend time learning some badly designed cli interface when I can focus on more important things and use tools that make my life easier, not harder.

greghinch 14y ago
git checkout bla.txt ? I'm not sure how I get how that's harder. I'll throw one back, how do I do the equivalent of git stash and git cherry-pick in hg?
- pka 14y ago
  Ah, good to know. Everytime I've googled this it was something about reset --hard (or --soft) and HEAD or ^HEAD or whatever else. git stash is hg shelve. Don't know about cherry picking (I've never needed it). Anyways, the argument I'm making is not "which tool is more powerful" but "which one is easier to use while being powerful enough". For me that is Mercurial, hands down.
  - greghinch 14y ago
    cherry-picking is amazing for the "oops I did that fix on master instead of the 2.x branch". git cherry-pick <hash>. done.
    - pka 14y ago
      Just for the record, the transplant extension [1] seems to be how you do cherry picking in Mercurial. [1] http://mercurial.selenic.com/wiki/TransplantExtension http://mercurial.selenic.com/wiki/TransplantExtension
      - retrogradeorbit 14y ago
        Transplant is a great extension and very useful in a pickle.
    - voltagex_ 14y ago
      Can you elaborate? I haven't had to use cherry-picking or rebasing and I'm not sure if I'm missing out on anything.
      - greghinch 14y ago
        Cherry picking: I forget to change to a branch where a commit was supposed to go, or I did a single commit change that needs to go across multiple branches without merging the entire branch. Do the commit, get the hash for the commit (git log is useful here) and switch to the branch where you want the change. git cherry-pick <hash> does a merge of just the single commit. Of course you can still end up with conflicts to fix, but git has been light years ahead of svn in doing merges, in my experience Rebase: Oops I committed something I shouldn't have. Must be done BEFORE you push. My favorite is git rebase -i HEAD~<n>, where n is usually something small like 5. You'll get a vim-like view where it lists each of the last n commits by hash and message. Delete the line for each commit you want to remove, save/quit, and git merges out those commits. Of course be cautious here because you can lose work completely. One more I like in the same vein, git commit --amend. For when you did a commit, and forgot to include something. This commit will just be added to the last.
  - regularfry 14y ago
    > git stash is hg shelve. Or hg qnew -f, which I personally prefer.

by pka 14y ago

greghinch 14y ago

git checkout bla.txt ? I'm not sure how I get how that's harder. I'll throw one back, how do I do the equivalent of git stash and git cherry-pick in hg?

pka 14y ago
Ah, good to know. Everytime I've googled this it was something about reset --hard (or --soft) and HEAD or ^HEAD or whatever else. git stash is hg shelve. Don't know about cherry picking (I've never needed it). Anyways, the argument I'm making is not "which tool is more powerful" but "which one is easier to use while being powerful enough". For me that is Mercurial, hands down.
- greghinch 14y ago
  cherry-picking is amazing for the "oops I did that fix on master instead of the 2.x branch". git cherry-pick <hash>. done.
  - pka 14y ago
    Just for the record, the transplant extension [1] seems to be how you do cherry picking in Mercurial. [1] http://mercurial.selenic.com/wiki/TransplantExtension http://mercurial.selenic.com/wiki/TransplantExtension
    - retrogradeorbit 14y ago
      Transplant is a great extension and very useful in a pickle.
  - voltagex_ 14y ago
    Can you elaborate? I haven't had to use cherry-picking or rebasing and I'm not sure if I'm missing out on anything.
    - greghinch 14y ago
      Cherry picking: I forget to change to a branch where a commit was supposed to go, or I did a single commit change that needs to go across multiple branches without merging the entire branch. Do the commit, get the hash for the commit (git log is useful here) and switch to the branch where you want the change. git cherry-pick <hash> does a merge of just the single commit. Of course you can still end up with conflicts to fix, but git has been light years ahead of svn in doing merges, in my experience Rebase: Oops I committed something I shouldn't have. Must be done BEFORE you push. My favorite is git rebase -i HEAD~<n>, where n is usually something small like 5. You'll get a vim-like view where it lists each of the last n commits by hash and message. Delete the line for each commit you want to remove, save/quit, and git merges out those commits. Of course be cautious here because you can lose work completely. One more I like in the same vein, git commit --amend. For when you did a commit, and forgot to include something. This commit will just be added to the last.
- regularfry 14y ago
  > git stash is hg shelve. Or hg qnew -f, which I personally prefer.