On Thu, Mar 18, 2010 at 1:19 PM, Michael Witten <mfwitten@xxxxxxxxx> wrote: > On Thu, Mar 18, 2010 at 11:36, Avery Pennarun <apenwarr@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html