On Fri, Sep 9, 2011 at 10:38, Greg Hudson <ghudson_at_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
Received on 2011-09-10 06:33:14 CEST