On Fri, Sep 9, 2011 at 10:38, Greg Hudson <ghud...@mit.edu> wrote: > On Fri, 2011-09-09 at 08:09 -0400, Greg Stein wrote: >> Greg Hudson said this is more akin to git stash than branches. I >> haven't used git's stashes to see how it actually differs from >> branches. I guess it is simply that changing branches leaves local >> mods, rather than stashing pseudo-reverts the local mods. > > * Branches record tree states, while stashes record changesets as > applied to the working copy and index. You can "git stash", "git > checkout branchname", and "git stash pop" the changeset such that it is > now applied against the new branch, if it applies cleanly. You can do > similar things with branches using rebase, but the sequence of > operations would be different and more complicated. > > * Stashes are a working copy feature, and aren't part of the history > model. This isn't necessarily an interesting distinction for us, but it > has some consequences within the universe of git--a subsidiary > repository's git fetch won't retrieve stashes, they won't be in the > target space of commit specifiers, you don't have to create commit > messages for them, etc.. > > Stashes don't make git more expressive than local branches and rebase, > but in some ways it's a useful UI concept to keep them separate.
Thanks for the extra detail! >> Mercurial calls it shelving. > > Aha. I'll note that shelving isn't a core feature of Mercurial but an > extension. Even if there are aliases so the command is accessible via > both names, the feature needs to have a primary name (which will be how > it's documented in the book, etc.). Yup. $ svn praise --help blame (praise, annotate, ann): Output the content of specified files or URLs with revision and author information in-line. usage: blame TARGET[@REV]... ... I will be lobbying for 'stash' as primary, and 'shelve' as an alias. Cheers, -g
