Re: Requesting `git stash --cached` or something similar

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 [off-list ref] wrote:

quoted

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 [off-list ref] [off-list ref]
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html