threads / discuss / 29281

Stashing individual files

Subject: Stashing individual files

## tl;dr

6 messages between Jan 2, 2012 and Jan 4, 2012.

replies: 5people: 4as markdown or json

Chris Leong· Jan 2, 2012, 23:32 UTC · lore
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
Jeff King· Jan 3, 2012, 19:06 UTC · re: Chris Leong · lore

Re: Stashing individual files

On Tue, Jan 03, 2012 at 10:32:02AM +1100, Chris Leong wrote:
Show 7 quoted lines
> 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
Junio C Hamano· Jan 3, 2012, 20:08 UTC · re: Jeff King · lore

Re: Stashing individual files

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.

Jeff King· Jan 3, 2012, 20:13 UTC · re: Junio C Hamano · lore

Re: Stashing individual files

On Tue, Jan 03, 2012 at 12:08:52PM -0800, Junio C Hamano wrote:
Show 7 quoted lines
> 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
Junio C Hamano· Jan 3, 2012, 20:45 UTC · re: Jeff King · lore

Re: Stashing individual files

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.
Tor Arntsen· Jan 4, 2012, 10:12 UTC · re: Jeff King · lore

Re: Stashing individual files

On Tue, Jan 3, 2012 at 20:06, Jeff King <peff@peff.net> wrote:
Show 10 quoted lines
> 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

← back to recent threads