Stashing individual files

Stashing individual files

[Chris Leong]

Hi all,

Thanks for making such a wonderful product. I find the stash command
really useful, but it doesn't work very well when I just need to
temporarily revert one or two files. I know that there is the
interactive command, but if you have modified a large number of files,
then it takes quite a bit of effort. Is there any way I can define an
alias, stashfiles, so that I can just type git stashfiles file1 file2?
Also, please consider adding such a feature into a future version.

Thanks,

Chris

Re: Stashing individual files

[Jeff King]

On Tue, Jan 03, 2012 at 10:32:02AM +1100, Chris Leong wrote:

> Thanks for making such a wonderful product. I find the stash command
> really useful, but it doesn't work very well when I just need to
> temporarily revert one or two files. I know that there is the
> interactive command, but if you have modified a large number of files,
> then it takes quite a bit of effort. Is there any way I can define an
> alias, stashfiles, so that I can just type git stashfiles file1 file2?
> Also, please consider adding such a feature into a future version.

I have sometimes wanted this, too. One problem is that the arguments in
a "stash save" get sucked into the message. I really wish it were:

  git stash save [-m <msg>] [[--] <pathspec...>]

which would match other git commands. And related, it would be nice to
have:

  git stash foo.c bar.c

but that conflicts with our safety-valve to avoid accidentally stashing
when no command is given.

For now, we could probably do it like this:

  git stash save [<message>] [-- <pathspec...>]

IOW, make the "--" a requirement for specifying filenames. The only
regression is that "--" as a single argument can no longer be used in
stash messages. So this works now:

  git stash save working on foo -- needs bar

but would be interpreted under my proposal as stashing "needs" and "bar"
with the message "working on foo". You would instead have to spell it:

  git stash save "working on foo -- needs bar"

I think that would be OK compromise, though. I'd rather not introduce a
whole new "stashfiles" command (or even a new subcommand of stash) if we
can avoid it.

-Peff

Re: Stashing individual files

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I think that would be OK compromise, though. I'd rather not introduce a
> whole new "stashfiles" command (or even a new subcommand of stash) if we
> can avoid it.

Why wouldn't a simple "git diff -- paths >P.diff" work?

What does such a partial stash leave in the working tree, how does the
user deal with the remaining local changes, what happens after such a
partial stash is applied/popped?

I wouldn't have worried about such a change before e0e2a9c (stash: drop
dirty worktree check on apply, 2011-04-05) but now we allow application of
stashed changes to the dirty working tree (which is a very good thing), I
am not sure how sensibly these changes in different places would interact
if we start supporting partial stashing.

Re: Stashing individual files

[Jeff King]

On Tue, Jan 03, 2012 at 12:08:52PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > I think that would be OK compromise, though. I'd rather not introduce a
> > whole new "stashfiles" command (or even a new subcommand of stash) if we
> > can avoid it.
> 
> Why wouldn't a simple "git diff -- paths >P.diff" work?

For all the same reasons that "git diff >P.diff" is not as good as a
regular stash.

> What does such a partial stash leave in the working tree, how does the
> user deal with the remaining local changes, what happens after such a
> partial stash is applied/popped?

I would expect it to stash only the changes in the selected files,
restoring them to their state in HEAD, and leave other files untouched.

We already have partial stashing like this via "git stash -p".  This is
just a shorthand for "say yes to all of the changes in foo.c, and no to
everything else". So I don't see it as particularly new or dangerous.

-Peff

Re: Stashing individual files

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> We already have partial stashing like this via "git stash -p".  This is
> just a shorthand for "say yes to all of the changes in foo.c, and no to
> everything else". So I don't see it as particularly new or dangerous.

Ok.

Re: Stashing individual files

[Tor Arntsen]

On Tue, Jan 3, 2012 at 20:06, Jeff King <peff@peff.net> wrote:

> IOW, make the "--" a requirement for specifying filenames. The only
> regression is that "--" as a single argument can no longer be used in
> stash messages. So this works now:
>
>  git stash save working on foo -- needs bar
>
> but would be interpreted under my proposal as stashing "needs" and "bar"
> with the message "working on foo". You would instead have to spell it:
>
>  git stash save "working on foo -- needs bar"

For what it's worth, that's how I always add messages to stash.. with
quotes. It had never occured to me to use the form
git stash save working on foo -- needs bar
(no quotes), it's so ingrained that a multi-word message should be
quoted that I would never have thought of even trying without the
quotes! :-)

-Tor