6 ms·

I'm glad that the shelve extension (which is like stash in git) is included by default now. Even though that extension has been around for a while, it feels lik

by toggle 13y ago

I'm glad that the shelve extension (which is like stash in git) is included by default now. Even though that extension has been around for a while, it feels like it's considered a core function now, rather than an "extra." (Especially for git users, who are accustomed to having `git stash` out of the box. So now there's a little less friction when trying to do the same things in Mercurial.)

twic 13y ago
Yes, it is nice to have shelve in the core. That said, with Git, my main use of stash is to put away uncommitted changes so i can pull updates from the origin. Stash, pull, pop. However, Mercurial is able to pull changes into a working copy which has uncommitted changes - it essentially just treats it as a merge. This, with Mercurial, i need to stash much less often. It's still useful as a way of putting changes aside while you work on something else, though, so i am glad to have it. The alternative was doing things with patch queues which were a bit scary.
- the_mitsuhiko 13y ago
  > Mercurial is able to pull changes into a working copy which has uncommitted changes - it essentially just treats it as a merge. This, with Mercurial, i need to stash much less often. JFTR: git 1.8.4 has --autostash as argument to rebase.
- beagle3 13y ago
  Is mercurial's merging significantly different than git pull --rebase? (which acts like "cvs update" or "svn update" with respect to uncommitted changes?)
  - twic 13y ago
    Is git pull --rebase like cvs update with respect to uncommitted changes? If i issue a git pull --rebase (with Git 1.8.2.2) in a repo in which i have uncommitted changes, i get: Cannot pull with rebase: You have unstaged changes. Please commit or stash them. From what i remember of CVS, if i update into a working copy with changes, it applies the update where it can, and leaves merge conflict markers (or runs your configured merge tool) where it can't. That is also what Mercurial does.
    - beagle3 13y ago
      Ok, now I understand. Yes, git expects you to commit or stash before doing that, matching the philosophy that there should be a commit you can go back to undo (even if you have to look at the reflog to see what that commit is). Personally, I commit and stash all the time, and feel better than the old CVS in which I manually stashed (by copying) the pre-"cvs update" state in case I needed to go back to it. matsushiko above mentions that git now has --autostash; legit had "sync" which does stash-rebase-unstash - but I rarely ever needed that workflow.

by toggle 13y ago

twic 13y ago

Yes, it is nice to have shelve in the core. That said, with Git, my main use of stash is to put away uncommitted changes so i can pull updates from the origin. Stash, pull, pop. However, Mercurial is able to pull changes into a working copy which has uncommitted changes - it essentially just treats it as a merge. This, with Mercurial, i need to stash much less often. It's still useful as a way of putting changes aside while you work on something else, though, so i am glad to have it. The alternative was doing things with patch queues which were a bit scary.

the_mitsuhiko 13y ago
> Mercurial is able to pull changes into a working copy which has uncommitted changes - it essentially just treats it as a merge. This, with Mercurial, i need to stash much less often. JFTR: git 1.8.4 has --autostash as argument to rebase.
beagle3 13y ago
Is mercurial's merging significantly different than git pull --rebase? (which acts like "cvs update" or "svn update" with respect to uncommitted changes?)
- twic 13y ago
  Is git pull --rebase like cvs update with respect to uncommitted changes? If i issue a git pull --rebase (with Git 1.8.2.2) in a repo in which i have uncommitted changes, i get: Cannot pull with rebase: You have unstaged changes. Please commit or stash them. From what i remember of CVS, if i update into a working copy with changes, it applies the update where it can, and leaves merge conflict markers (or runs your configured merge tool) where it can't. That is also what Mercurial does.
  - beagle3 13y ago
    Ok, now I understand. Yes, git expects you to commit or stash before doing that, matching the philosophy that there should be a commit you can go back to undo (even if you have to look at the reflog to see what that commit is). Personally, I commit and stash all the time, and feel better than the old CVS in which I manually stashed (by copying) the pre-"cvs update" state in case I needed to go back to it. matsushiko above mentions that git now has --autostash; legit had "sync" which does stash-rebase-unstash - but I rarely ever needed that workflow.