Thomas Gummerer <t.gummerer@xxxxxxxxx> writes: > While working on a repository, it's often helpful to stash the changes > of a single or multiple files, and leave others alone. Unfortunately > git currently offers no such option. git stash -p can be used to work > around this, but it's often impractical when there are a lot of changes > over multiple files. > > Add a --file option to git stash save, which allows for stashing a > single file. Specifying the --file argument multiple times allows > stashing more than one file at a time. > > Signed-off-by: Thomas Gummerer <t.gummerer@xxxxxxxxx> > --- > > Marked as RFC and without documentation updates to first get a feeling > for the user interface, and whether people are interested in this > change. > > Ideally I wanted the the user interface to look like something like: > git stash save -- [<filename1,...>], but unfortunately that's already > taken up by the stash message. So to preserve backward compatibility > I used the new --file argument. I haven't spent enough time to think if it even makes sense to "stash" partially, leaving the working tree still dirty. My initial reaction was "then stashing away the dirty WIP state to get a spiffy clean working environment becomes impossible", and I still need time to recover from that ;-) So as to the desirablity of this "feature", I have no strong opinion for or against yet. But if we were to do this, then we should bite the bullet and declare that "stash save <message>" was a mistake. It should have been "stash save -m <message>" and we should transition to that (one easy way out would be to find another verb that is not 'save'). Then we can do "git stash save [-m <msg>] [--] [pathspec...]" which follows the usual command line convention.