On Mon, Apr 13, 2015 at 10:05:02PM -0400, Brandon McCaig wrote: > Trevor: > > On Mon, Apr 13, 2015 at 9:44 PM, Trevor Saunders <tbsau...@tbsaunde.org> > wrote: > > I would expect the answers to be it sets the working directories state > > to the state in HEAD, and leaves untracked files alone. If that's what > > you want you can do git commit -m <message>; git reset --hard; git reset > > --soft; git stash save to get the effect you want I believe. That said > > it seems like a kind of odd thing to want to do, what are you actually > > trying to do? > > That looks like a bad solution. git reset --hard is going to throw > away any remaining changes to the working tree. The previous commit
git reset --hard is there to do *exactly* that, which I'm assuming is the desired thing for a hypothetical git stash save --cached to do because its consistant with what git stash save does. > would have committed the staged changes, albeit, you should connect > the commands with && instead of ; to account for errors. After a `git it should be clear this is not actual code to run exactly as written. > reset --hard' there's no point in doing a `git reset --soft' because > hard does *everything*. --soft would try to reset the HEAD without > touching the index or working tree, but both have already been reset > with --hard. yes, that was supposed to be git reset --soft HEAD~ in which case it does do something, and it is there exactly to just reset HEAD so that git stash can then pick up the changes from the temporary commit. > The motivation is most likely stashing a few changes away so that you > can commit others that are ready to be committed while keeping others > around to continue working on them. This too is a good observation. It yes, it could be they are looking for something like git stash --patch, but maybe not we don't know. > could mean that the OP is inexperienced with a commit-often workflow. > You can use git -add -i or -p to commit the good stuff and keep the > bad stuff out to work on it more. The great thing about Git is that > the history is very malleable. You can also commit the bad and fix it > after, rebase the history to clean it up, and end up with perfect > history while still keeping your changes safely in history. git stash also stores changes in the git database. However if you really like the stack / queue type workflow you might want to consider stgit or stacked git or something (I personally really dislike that work flow so I'm not really familiar with those tools). > The OP should experiment with workflows because Git is already very > good at this. Stash isn't really needed. That said, I had forgotten > that --patch was added to stash some time ago so if that is what you > want then it already exists. It's not quite as easy as --cached, but > it still gives you some control. It's still not nearly as good as > using the full power of Git with a regular commit on a branch though. good is subjective and depends on what you need to do. There are certainly times where the stash is a good way to solve problems, and if people have ideas for things they think it can do better that's great. Trev > > Regards, > > -- > Brandon McCaig <bamcc...@gmail.com> <bamcc...@castopulence.org> > Castopulence Software <https://www.castopulence.org/> > Blog <http://www.bambams.ca/> > perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }. > q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.}; > tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say' > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
