From: Avery Pennarun Date: Thu, 18 Mar 2010 17:33:18 GMT Subject: Re: [PATCH] Clarification for the command "git checkout " Message-ID: <32541b131003181033p7916d92frc1269b95c292e3db@mail.gmail.com> In-Reply-To: On Thu, Mar 18, 2010 at 1:19 PM, Michael Witten wrote: > On Thu, Mar 18, 2010 at 11:36, Avery Pennarun wrote >> stashing isn't really something you'd want to do on a per-branch >> basis.  Most of the point is that you stash away your changes, then >> switch to another branch, then restore your stash to your *current* >> working state sometime later. > > As you may know, "git checkout" carries local modifications to the new > working tree if there are no conflicts, so no explicit stash usage is > necessary in many cases. I'm almost never lucky enough that switching branches won't touch the same files as the ones I've been editing (especially Makefile). I imagine this works better with larger repositories like the Linux kernel. But my fingers have learned that if I do 'git stash' it always works, while if I don't it doesn't always work, so I stash without thinking nowadays. The other big advantage of using stash is that your half-done files end up in the repo, so if you later screw up by doing something idiotic like 'git reset --hard' at the wrong time, you can still get it back. I love that feeling of safety. > Anyway, I think it would be useful to be able to manage multiple > stashes rather than having to rely on just one global stash. However, > I imagine than explicit Work In Progress (WIP) commits as sketched > above would go a long way in keeping histories and workflows clean and > organized. The stash can contain multiple entries. They're stored in a stack, but you can pull prior entries out of the stack if you want. Personally, I don't need anything more. Have fun, Avery