From: Jeff King <peff@peff.net>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Anders Melchiorsen <mail@cup.kalibalik.dk>,
Brandon Casey <casey@nrlssc.navy.mil>,
David Kastrup <dak@gnu.org>,
git@vger.kernel.org
Subject: Re: Usability of git stash
Date: Sun, 19 Oct 2008 20:36:44 -0400 [thread overview]
Message-ID: <20081020003644.GA10412@coredump.intra.peff.net> (raw)
In-Reply-To: <20081019184029.GF14786@spearce.org>
On Sun, Oct 19, 2008 at 11:40:30AM -0700, Shawn O. Pearce wrote:
> Ditto. I never use "git stash". Its command line usage is too
> unfriendly for me, so I tend to prefer making WIP commits. If I
> need to stash something I'll do:
>
> git commit -a -m wip
> ... some time later ..
> git checkout branch
> git reset --soft HEAD^
That's what I do, too, except when I want to move changes from one
branch to another, or split some changes from their history. So
something like:
git checkout next ;# which is where I usually am anyway
hack hack hack
# oops, I have been building this directly on top of next and it
# really needs to be a feature-branch on maint
git stash
git checkout -b jk/maint-fix-whatever origin/maint
git stash apply
The equivalent non-stash commands would be "commit -m wip" and
"cherry-pick". But the stash saves me the trouble later of having to
delete the wip cruft on top of next.
Side note: obviously this uses the stash only as a push/pop stack. I
have never personally had a situation where I wanted a named stash or
multiple stashes over a wip commit.
> Personally I wish git-stash wasn't invented the way it is. I would
> have rather seen it as macros to do a quick:
>
> git commit -m wip-index-state
> git commit -A -m wip-worktree-state
>
> and unwind it with essentially:
>
> git reset --mixed HEAD^
> git reset --soft HEAD^
I disagree. I think the strength of stash is that it is divorced from
the history. So it is more like a cherry-pick (or diff | apply, which is
what it was intended to replace).
> time they ran the stash. I think its rare you'd stash something
> then switch to another branch to apply it. But that could easily
> be done with cherry-pick.
I guess we are viewing the tool oppositely. :)
-Peff
next prev parent reply other threads:[~2008-10-20 0:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-15 19:24 Usability of git stash Anders Melchiorsen
2008-10-15 19:31 ` Brandon Casey
2008-10-16 11:24 ` David Kastrup
2008-10-16 15:22 ` Brandon Casey
2008-10-18 9:26 ` Anders Melchiorsen
2008-10-19 18:40 ` Shawn O. Pearce
2008-10-19 21:08 ` Leo Razoumov
2008-10-19 21:49 ` Shawn O. Pearce
2008-10-19 23:12 ` Stephan Beyer
2008-10-20 9:36 ` Miles Bader
2008-10-20 0:36 ` Jeff King [this message]
2008-10-20 5:29 ` Junio C Hamano
2008-10-20 5:23 ` Miles Bader
2008-10-20 9:49 ` Andreas Ericsson
2008-10-20 16:33 ` Brandon Casey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081020003644.GA10412@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=casey@nrlssc.navy.mil \
--cc=dak@gnu.org \
--cc=git@vger.kernel.org \
--cc=mail@cup.kalibalik.dk \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).