> After all, if they are related, > you're more likely not keeping the work in the stash entries---you'd > rather be making completed commit on the branch. I don't if this the use case of Yuri, but in the past I kept a stash entry with some local development changes that shouldn't be committed and sent to the main repository. This is, I always applied that stash entry, did what I needed in my local environment, removed the code that was applied, then I committed the changes that should went to production. It soon became hard to manage as I needed to use stash for other things. But hey, stash entries are commits, so I could somehow mimic its behavior without using stash itself! So, what I did: 1. Detached the HEAD: $ git checkout --detach 2. Committed the local development changes. You can use the commit message body to write a description of what those changes are. $ git add my_changed_file $ git commit 3. Created a local tag, just for me: $ git tag LOCAL_SETUP 4. Whenever I wanted to use that code, I just applied it by using: $ git merge --squash LOCAL_SETUP $ git reset This left the Git stash stack free for other uses and I could use it without worrying about the stash positions. If the problem is to have control over the stash, maybe the solution is to use the good old commits. > ... this is an excellent suggestion. Thanks :-)
