Re: [PATCH] Clarification for the command "git checkout <branch>"

[Avery Pennarun <apenwarr@gmail.com>]

On Thu, Mar 18, 2010 at 1:19 PM, Michael Witten <mfwitten@gmail.com> wrote:
> On Thu, Mar 18, 2010 at 11:36, Avery Pennarun <apenwarr@gmail.com> 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