git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] stash: support filename argument

From
Thomas Gummerer <t.gummerer@gmail.com>
Date
Jan 16, 2017, 22:29 UTC
Message-ID
<20170116222927.GA31189@hank>
In-Reply-To
<xmqqvatfc0rt.fsf@gitster.mtv.corp.google.com>
On 01/15, Junio C Hamano wrote:
Show 30 quoted lines
> Thomas Gummerer <t.gummerer@gmail.com> 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@gmail.com>
> > ---
> >
> > 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.

As others mentioned, this would be similar to stash -p. My main usecase is stashing away a config file or changes in one test file while I forget to test something without these changes. I definitely used git stash -p on more than one occasion to simulate this behaviour before.

Show 7 quoted lines
> 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.

I like this interface much better than the one in my patch. I'm not sure about the verb we could use for the transition, maybe 'push'. If anyone can come up with a different suggestion I'd be happy to hear it, as I'm not very good at naming things.

-- 
Thomas
Previous: Johannes Schindelin
Message 8 of 8 in “[RFC] stash: support filename argument”
  1. Thomas GummererJan 15, 2017
  2. Junio C HamanoJan 16, 2017
  3. Stephan BeyerJan 16, 2017
  4. Marc StrapetzJan 16, 2017
  5. Jeff KingJan 16, 2017
  6. Johannes SchindelinJan 16, 2017
  7. Johannes SchindelinJan 16, 2017
  8. Thomas GummererJan 16, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.